Re: [PATCH v1] asm-generic: introduce be56 unaligned accessors

[Marius.Cristea]

On Mon, 2024-10-07 at 14:44 +0000, Arnd Bergmann wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> 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.
> 
>         Arnd

Most probably this request is quite specific to my driver and I'm not
sure how often it will be used by somebody else.

I'm using block read in order to get multiple registers at a time
(around 76 bytes) and to increase the efficiency of the transfer over
I2C. Being a block read there are different registers length involved
from 16 up to 56 bits long and I need to unpack.

//Marius