From: Ping-Ke Shih <pkshih@realtek.com>
To: "martin.blumenstingl@googlemail.com"
<martin.blumenstingl@googlemail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"kvalo@kernel.org" <kvalo@kernel.org>,
"tehuang@realtek.com" <tehuang@realtek.com>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"tony0620emma@gmail.com" <tony0620emma@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] rtw88: Add packed attribute to the eFuse structs
Date: Thu, 29 Dec 2022 11:35:59 +0000 [thread overview]
Message-ID: <a04c0a270ca095495e24af6950a462142aa199b8.camel@realtek.com> (raw)
In-Reply-To: <CAFBinCBKuTsK21CxEhth5js4Quyy0iUg6ctZwEQwwarePgghaQ@mail.gmail.com>
On Thu, 2022-12-29 at 11:37 +0100, Martin Blumenstingl wrote:
> Hi Ping-Ke,
>
> On Thu, Dec 29, 2022 at 10:25 AM Ping-Ke Shih <pkshih@realtek.com> wrote:
> [...]
> > > @@ -43,13 +43,13 @@ struct rtw8821ce_efuse {
> > > u8 link_cap[4];
> > > u8 link_control[2];
> > > u8 serial_number[8];
> > > - u8 res0:2; /* 0xf4 */
> > > - u8 ltr_en:1;
> > > - u8 res1:2;
> > > - u8 obff:2;
> > > - u8 res2:3;
> > > - u8 obff_cap:2;
> > > - u8 res3:4;
> > > + u16 res0:2; /* 0xf4 */
> > > + u16 ltr_en:1;
> > > + u16 res1:2;
> > > + u16 obff:2;
> > > + u16 res2:3;
> > > + u16 obff_cap:2;
> > > + u16 res3:4;
> >
> > These should be __le16. Though bit fields are suitable to efuse layout,
> > we don't access these fields for now. It would be well.
> My understanding is that it should look like this (replacing all of res0..res3):
> __le16 some_field_name; /* 0xf4 */
> How to call that single __le16 field then?
You are right. Maybe, we can name it 'pcie_cap'.
But, we don't use them for now, so it is harmless to preserve them as is.
>
> I also tried using bit-fields for an __le16 (so basically the same as
> my patch but using __le16 instead of u16) but that makes sparse
> complain:
> error: invalid bitfield specifier for type restricted __le16
>
>
We can fix it by:
u8 res0:2; /* 0xf4 */
u8 ltr_en:1;
u8 res1:2;
u8 obff:2;
- u8 res2:3;
+ u8 res2_1:1;
+ u8 res2_2:2;
u8 obff_cap:2;
u8 res3:4;
I'm not sure why people merge bit fields res2_1:1 and res2_2:2 that
should be in different u8. I have confirmed this with internal data.
--
Ping-Ke
next prev parent reply other threads:[~2022-12-29 11:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-28 13:35 [PATCH 0/4] rtw88: Four fixes found while working on SDIO support Martin Blumenstingl
2022-12-28 13:35 ` [PATCH 1/4] rtw88: Add packed attribute to the eFuse structs Martin Blumenstingl
2022-12-29 9:24 ` Ping-Ke Shih
2022-12-29 10:37 ` Martin Blumenstingl
2022-12-29 11:35 ` Ping-Ke Shih [this message]
2022-12-31 16:57 ` David Laight
2023-01-01 11:42 ` Ping-Ke Shih
2023-01-01 11:54 ` David Laight
2023-01-01 13:08 ` Ping-Ke Shih
2023-01-04 15:30 ` Martin Blumenstingl
2023-01-04 15:53 ` David Laight
2023-01-04 16:07 ` Martin Blumenstingl
2023-01-04 16:31 ` David Laight
2023-01-04 17:49 ` Martin Blumenstingl
2023-01-05 0:56 ` Ping-Ke Shih
2023-01-05 8:34 ` David Laight
2023-01-10 12:02 ` Kalle Valo
2023-01-10 12:34 ` David Laight
2022-12-28 13:35 ` [PATCH 2/4] rtw88: Configure the registers from rtw_bf_assoc() outside the RCU lock Martin Blumenstingl
2022-12-29 9:37 ` Ping-Ke Shih
2022-12-28 13:35 ` [PATCH 3/4] rtw88: Use rtw_iterate_vifs() for rtw_vif_watch_dog_iter() Martin Blumenstingl
2022-12-29 9:39 ` Ping-Ke Shih
2022-12-28 13:35 ` [PATCH 4/4] rtw88: Use non-atomic rtw_iterate_stas() in rtw_ra_mask_info_update() Martin Blumenstingl
2022-12-29 9:39 ` Ping-Ke Shih
2022-12-29 9:26 ` [PATCH 0/4] rtw88: Four fixes found while working on SDIO support Ping-Ke Shih
2022-12-29 10:40 ` Martin Blumenstingl
2022-12-29 11:42 ` Ping-Ke Shih
2023-01-10 12:06 ` Kalle Valo
2022-12-29 12:48 Martin Blumenstingl
2022-12-29 12:48 ` [PATCH 1/4] rtw88: Add packed attribute to the eFuse structs Martin Blumenstingl
2022-12-29 23:47 ` Ping-Ke Shih
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a04c0a270ca095495e24af6950a462142aa199b8.camel@realtek.com \
--to=pkshih@realtek.com \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=netdev@vger.kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=tehuang@realtek.com \
--cc=tony0620emma@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®