From: Arnd Bergmann > Sent: 07 October 2024 15:45 > On Mon, Oct 7, 2024, at 14:40, Marius.Cristea@xxxxxxxxxxxxx wrote: > > On Sun, 2024-09-29 at 21:16 +0000, David Laight wrote: > >> [You don't often get email from david.laight@xxxxxxxxxx. Learn why > >> this is important at https://aka.ms/LearnAboutSenderIdentification ;] > >> > >> EXTERNAL EMAIL: Do not click links or open attachments unless you > >> know the content is safe > >> > >> From: marius.cristea@xxxxxxxxxxxxx > >> > Sent: 27 September 2024 09:36 > >> > > >> > The PAC194X, IIO driver, is using some unaligned 56 bit registers. > >> > Provide some helper accessors in preparation for the new driver. > >> > >> Someone please shoot the hardware engineer ;-) > >> > >> Do separate unaligned access of the first 4 bytes and last four > >> bytes. > >> It can't matter if the middle byte is accessed twice. > >> > >> Or, for reads read 8 bytes from 'p & ~1ul' and then fixup > >> the value. > >> > > > > Do you recommend me to drop this patch? > > > > I know that there are some "workarounds", but those didn't "looks" > > nice. I was using that function locally and I got a suggestion from the > > IIO subsystem maintainer to move it into the kernel in order for others > > to used it. > > My feeling is that this is too specific to one driver, I don't > expect it to be shared much. I also suspect that most 56-bit > integers in data structures are actually always part of a naturally > aligned 64-bit word. If that is the case here, the driver can > probably better access it as a normal 64-bit number and mask > out the upper 56 bits using the include/linux/bitfield.h helpers. Or get the compiler to do it for you. This DTRT https://www.godbolt.org/z/GMdePjYMY: struct foo { unsigned long a; unsigned char b; unsigned long c:56 __attribute__((packed)); unsigned long d; }; Although you'll need #define htobe56(x) (htobe64(x) >> 8) on LE. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
