From: Sudeep Holla <sudeep.holla@arm.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>
Subject: Re: [PATCH] firmware: arm_scmi: Use {get,put}_unaligned_le32 accessors
Date: Wed, 7 Aug 2019 18:08:09 +0100 [thread overview]
Message-ID: <20190807170808.GD27278@e107155-lin> (raw)
In-Reply-To: <4102ce79ef7a4f5ba819663d072bccc8@AcuMS.aculab.com>
On Wed, Aug 07, 2019 at 03:18:59PM +0000, David Laight wrote:
> From: Sudeep Holla
> > Sent: 07 August 2019 14:01
> >
> > Instead of type-casting the {tx,rx}.buf all over the place while
> > accessing them to read/write __le32 from/to the firmware, let's use
> > the nice existing {get,put}_unaligned_le32 accessors to hide all the
> > type cast ugliness.
>
> Why the 'unaligned' accessors?
>
Since the firmware run in LE, we do byte-swapping anyways.
> > - *(__le32 *)t->tx.buf = cpu_to_le32(id);
> > + put_unaligned_le32(id, t->tx.buf);
>
If you look at the generic definition for put_unaligned_le32, it's
exactly the same as what I am replacing with the call. So nothing
changes IIUC. In fact, I see that all the helper in unaligned/access_ok.h
just do the byte-swapping.
> These will be expensive if the cpu doesn't support them.
The SCMI is currently used only on ARM platforms which have
HAVE_EFFICIENT_UNALIGNED_ACCESS defined.
--
Regards,
Sudeep
next prev parent reply other threads:[~2019-08-07 17:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 13:00 [PATCH] firmware: arm_scmi: Use {get,put}_unaligned_le32 accessors Sudeep Holla
2019-08-07 13:36 ` Philipp Zabel
2019-08-07 13:57 ` Sudeep Holla
2019-08-07 14:07 ` Robin Murphy
2019-08-07 14:37 ` Sudeep Holla
2019-08-07 15:18 ` David Laight
2019-08-07 17:08 ` Sudeep Holla [this message]
2019-08-07 17:37 ` [PATCH v2] firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessors Sudeep Holla
2019-08-08 9:47 ` Philipp Zabel
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=20190807170808.GD27278@e107155-lin \
--to=sudeep.holla@arm.com \
--cc=David.Laight@ACULAB.COM \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
/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).