From: <Marius.Cristea@microchip.com>
To: <arnd@arndb.de>, <David.Laight@aculab.com>
Cc: <linux-arch@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] asm-generic: introduce be56 unaligned accessors
Date: Mon, 7 Oct 2024 14:57:23 +0000 [thread overview]
Message-ID: <2f53046dd5b791845c2ffa783d7637ca94ca330c.camel@microchip.com> (raw)
In-Reply-To: <758e1d68-3a27-4d64-8c45-da829ed5904a@app.fastmail.com>
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@microchip.com wrote:
> > On Sun, 2024-09-29 at 21:16 +0000, David Laight wrote:
> > > [You don't often get email from david.laight@aculab.com. 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@microchip.com
> > > > 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
next prev parent reply other threads:[~2024-10-07 14:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-27 8:35 [PATCH v1] asm-generic: introduce be56 unaligned accessors marius.cristea
2024-09-29 21:16 ` David Laight
2024-10-07 14:40 ` Marius.Cristea
2024-10-07 14:44 ` Arnd Bergmann
2024-10-07 14:57 ` Marius.Cristea [this message]
2024-10-07 17:08 ` Arnd Bergmann
2024-10-08 9:03 ` David Laight
2024-10-07 15:05 ` David Laight
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=2f53046dd5b791845c2ffa783d7637ca94ca330c.camel@microchip.com \
--to=marius.cristea@microchip.com \
--cc=David.Laight@aculab.com \
--cc=arnd@arndb.de \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).