From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Mateusz Holenko <mholenko@antmicro.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.com>,
devicetree@vger.kernel.org,
"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>
Cc: Stafford Horne <shorne@gmail.com>,
Karol Gugala <kgugala@antmicro.com>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
"Paul E. McKenney" <paulmck@linux.ibm.com>,
Filip Kokosinski <fkokosinski@antmicro.com>,
Pawel Czarnecki <pczarnecki@internships.antmicro.com>,
Joel Stanley <joel@jms.id.au>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Maxime Ripard <mripard@kernel.org>,
Shawn Guo <shawnguo@kernel.org>, Heiko Stuebner <heiko@sntech.de>,
Sam Ravnborg <sam@ravnborg.org>, Icenowy Zheng <icenowy@aosc.io>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
linux-kernel@vger.kernel.org,
"Gabriel L. Somlo" <gsomlo@gmail.com>
Subject: Re: [PATCH v5 3/5] drivers/soc/litex: add LiteX SoC Controller driver
Date: Wed, 29 Apr 2020 13:21:11 +1000 [thread overview]
Message-ID: <55e1e941457cd596c4273e9c55dc2cfc9027c5ba.camel@kernel.crashing.org> (raw)
In-Reply-To: <CAPk366REVxz7qRfJ0dJOVPRey6+01q1JRvqANDNffYV8Lvh73g@mail.gmail.com>
On Mon, 2020-04-27 at 11:13 +0200, Mateusz Holenko wrote:
> As Gabriel Somlo <gsomlo@gmail.com> suggested to me, I could still use
> readl/writel/ioread/iowrite() standard functions providing memory
> barriers *and* have values in CPU native endianness by using the
> following constructs:
>
> `le32_to_cpu(readl(addr))`
>
> and
>
> `writel(cpu_to_le32(value), addr)`
>
> as le32_to_cpu/cpu_to_le32():
> - does nothing on LE CPUs and
> - reorders bytes on BE CPUs which in turn reverts swapping made by
> readl() resulting in returning the original value.
It's a bit sad... I don't understand why you need this. The HW has a
fied endian has you have mentioned earlier (and that is a good design).
The fact that you are trying to shove things into a "smaller pipe" than
the actual register shouldn't affect at what address the MSB and LSB
reside. And readl/writel (or ioread32/iowrite32) will always be LE as
well, so will match the HW layout. Thus I don't see why you need to
play swapping games here.
This however would be avoided completely if the HW was a tiny bit
smarter and would do the multi-beat access for you which shouldn't be
terribly hard to implement.
That said, it would be even clearer if you just open coded the 2 or 3
useful cases: 32/8, 32/16 and 32/32. The loop with calculated shifts
(and no masks) makes the code hard to understand.
Cheers,
Ben.
next prev parent reply other threads:[~2020-04-29 3:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-25 11:41 [PATCH v5 0/5] LiteX SoC controller and LiteUART serial driver Mateusz Holenko
2020-04-25 11:41 ` [PATCH v5 1/5] dt-bindings: vendor: add vendor prefix for LiteX Mateusz Holenko
2020-04-25 11:41 ` [PATCH v5 2/5] dt-bindings: soc: document LiteX SoC Controller bindings Mateusz Holenko
2020-04-25 11:42 ` [PATCH v5 3/5] drivers/soc/litex: add LiteX SoC Controller driver Mateusz Holenko
2020-04-27 9:13 ` Mateusz Holenko
2020-04-29 3:21 ` Benjamin Herrenschmidt [this message]
2020-04-29 11:32 ` Gabriel L. Somlo
2020-04-29 3:11 ` Benjamin Herrenschmidt
2020-05-07 7:36 ` Mateusz Holenko
2020-04-25 11:42 ` [PATCH v5 4/5] dt-bindings: serial: document LiteUART bindings Mateusz Holenko
2020-04-25 11:42 ` [PATCH v5 5/5] drivers/tty/serial: add LiteUART driver Mateusz Holenko
2020-04-28 15:50 ` Andy Shevchenko
2020-05-04 13:44 ` Mateusz Holenko
2020-05-05 14:02 ` Andy Shevchenko
2020-05-08 10:16 ` Mateusz Holenko
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=55e1e941457cd596c4273e9c55dc2cfc9027c5ba.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=fkokosinski@antmicro.com \
--cc=gregkh@linuxfoundation.org \
--cc=gsomlo@gmail.com \
--cc=heiko@sntech.de \
--cc=icenowy@aosc.io \
--cc=joel@jms.id.au \
--cc=jslaby@suse.com \
--cc=kgugala@antmicro.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mchehab+samsung@kernel.org \
--cc=mholenko@antmicro.com \
--cc=mripard@kernel.org \
--cc=paulmck@linux.ibm.com \
--cc=pczarnecki@internships.antmicro.com \
--cc=robh+dt@kernel.org \
--cc=sam@ravnborg.org \
--cc=shawnguo@kernel.org \
--cc=shorne@gmail.com \
/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).