lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <eee17e2f4e44a2f38021a839dc39fedc1c1a4141.camel@realtek.com> Date: Sun, 1 Jan 2023 11:42:25 +0000 From: Ping-Ke Shih <pkshih@...ltek.com> To: "martin.blumenstingl@...glemail.com" <martin.blumenstingl@...glemail.com>, "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>, "David.Laight@...LAB.COM" <David.Laight@...LAB.COM> CC: "kvalo@...nel.org" <kvalo@...nel.org>, "tehuang@...ltek.com" <tehuang@...ltek.com>, "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>, "tony0620emma@...il.com" <tony0620emma@...il.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 1/4] rtw88: Add packed attribute to the eFuse structs On Sat, 2022-12-31 at 16:57 +0000, David Laight wrote: > From: Ping-Ke Shih > > Sent: 29 December 2022 09:25 > > > > > -----Original Message----- > > > From: Martin Blumenstingl <martin.blumenstingl@...glemail.com> > > > Sent: Wednesday, December 28, 2022 9:36 PM > > > To: linux-wireless@...r.kernel.org > > > Cc: tony0620emma@...il.com; kvalo@...nel.org; Ping-Ke Shih <pkshih@...ltek.com>; > > tehuang@...ltek.com; > > > s.hauer@...gutronix.de; netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Martin > > > Blumenstingl > > > <martin.blumenstingl@...glemail.com> > > > Subject: [PATCH 1/4] rtw88: Add packed attribute to the eFuse structs > > > > > > The eFuse definitions in the rtw88 are using structs to describe the > > > eFuse contents. Add the packed attribute to all structs used for the > > > eFuse description so the compiler doesn't add gaps or re-order > > > attributes. > > > > > > Also change the type of the res2..res3 eFuse fields to u16 to avoid the > > > following warning, now that their surrounding struct has the packed > > > attribute: > > > note: offset of packed bit-field 'res2' has changed in GCC 4.4 > > > > > > Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") > > > Fixes: ab0a031ecf29 ("rtw88: 8723d: Add read_efuse to recognize efuse info from map") > > > Fixes: 769a29ce2af4 ("rtw88: 8821c: add basic functions") > > > Fixes: 87caeef032fc ("wifi: rtw88: Add rtw8723du chipset support") > > > Fixes: aff5ffd718de ("wifi: rtw88: Add rtw8821cu chipset support") > > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@...glemail.com> > > > --- > > > drivers/net/wireless/realtek/rtw88/main.h | 6 +++--- > > > drivers/net/wireless/realtek/rtw88/rtw8723d.h | 6 +++--- > > > drivers/net/wireless/realtek/rtw88/rtw8821c.h | 20 +++++++++---------- > > > drivers/net/wireless/realtek/rtw88/rtw8822b.h | 20 +++++++++---------- > > > drivers/net/wireless/realtek/rtw88/rtw8822c.h | 20 +++++++++---------- > > > 5 files changed, 36 insertions(+), 36 deletions(-) > > > > > > > [...] > > > > > @@ -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. Uh. I typo the sentence. Originally, I would like to type "...bit fields are NOT suitable...". In this driver, efuse is read into a u8 array, and cast to this struct pointer to access the field. > > IIRC the assignment of actual bits to bit-fields is (at best) > architecturally defined - so isn't really suitable for anything > where the bits have to match a portable memory buffer. > The bit allocation isn't tied to the byte endianness. Yes, this kind of struct has endian problem. Fortunately, we don't actually access values via bit fields. > > To get an explicit layout you have to do explicit masking. If we actually want to access these values, we will define masks and use {u8,_le16,le32}_get_bits() or bare '&' bit operation to access them. > > You also don't need __packed unless the 'natural' alignment > of fields would need gaps or the actual structure itself might > be misaligned in memory. > While C compilers are allowed to add arbitrary padding the Linux kernel > requires that they don't. > I'm also pretty sure that compilers are not allowed to reorder fields. > > Specifying __packed can add considerable run-time (and code size) > overhead on some architectures - it should only be used if actually > needed. > Understood. We only add __packed to the struct which is used to access predefined format, like efuse content defined by vendor. Ping-Ke
Powered by blists - more mailing lists