From: Logan Gunthorpe <logang@deltatee.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
linux-ntb@googlegroups.com,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Andy Shevchenko" <andy.shevchenko@gmail.com>,
"Horia Geantă" <horia.geanta@nxp.com>,
"Philippe Ombredanne" <pombredanne@nexb.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Kate Stewart" <kstewart@linuxfoundation.org>,
"Luc Van Oostenryck" <luc.vanoostenryck@gmail.com>
Subject: Re: [PATCH v13 01/10] iomap: Use correct endian conversion function in mmio_writeXXbe
Date: Mon, 26 Mar 2018 10:21:43 -0600 [thread overview]
Message-ID: <726eb143-2cca-b221-b569-e193a962e357@deltatee.com> (raw)
In-Reply-To: <CAK8P3a25zQDxyaY3iVv+JmSSzs7F6ssGc+HdBkGs54ZfViX+Fg@mail.gmail.com>
On 26/03/18 04:53 AM, Arnd Bergmann wrote:
> On most architectures, this is not important:
> - For x86, the stores are aways atomic and no additional barriers
> are needed, so the two are the same
> - For ARM (both 32 and 64-bit), powerpc and many others, we don't
> use the generic iowrite() and just fall back to writel() or
> writel(swab32()).
>
> However, shouldn't we just use the writel(swab32()) logic here as well
> for the common case rather than risking missing barriers?
Hmm, I don't know... it's complicated?
Doing a bit of digging shows that the existing code was written during a
time when writel() did not include extra barriers over __raw_writel() in
any of the common arches.
The commit logs don't seem to provide any guidance as to why this it was
done this way, but I'd assume it was done to avoid a double swab() call
on BE arches. Seeing writel() is typically implemented as:
__raw_writel(__cpu_to_le32(value), addr);
Then on BE arches, writel(swab32()) would become:
__raw_writel(swab32(swab32(value)), addr)
Which seems undesirable.
Logan
next prev parent reply other threads:[~2018-03-26 16:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 16:37 [PATCH v13 00/10] Add io{read|write}64 to io-64-atomic headers Logan Gunthorpe
2018-03-21 16:37 ` Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 01/10] iomap: Use correct endian conversion function in mmio_writeXXbe Logan Gunthorpe
2018-03-21 16:37 ` Logan Gunthorpe
2018-03-21 17:28 ` Luc Van Oostenryck
2018-03-21 17:28 ` Luc Van Oostenryck
2018-03-26 10:53 ` Arnd Bergmann
2018-03-26 10:53 ` Arnd Bergmann
2018-03-26 16:21 ` Logan Gunthorpe [this message]
2018-03-26 16:21 ` Logan Gunthorpe
2018-03-26 19:50 ` Arnd Bergmann
2018-03-26 19:50 ` Arnd Bergmann
2018-03-26 20:33 ` Logan Gunthorpe
2018-03-26 20:33 ` Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 02/10] iomap: Fix sparse endian check warnings Logan Gunthorpe
2018-03-21 16:37 ` Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 03/10] parisc: iomap: introduce io{read|write}64 Logan Gunthorpe
2018-03-21 16:37 ` Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 04/10] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs Logan Gunthorpe
2018-03-21 16:37 ` Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 05/10] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo} Logan Gunthorpe
2018-03-21 16:37 ` Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 06/10] iomap: " Logan Gunthorpe
2018-03-21 16:37 ` Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 07/10] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros Logan Gunthorpe
2018-03-21 16:37 ` Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 08/10] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks Logan Gunthorpe
2018-03-21 16:37 ` Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 09/10] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64 Logan Gunthorpe
2018-03-21 16:37 ` Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 10/10] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header Logan Gunthorpe
2018-03-21 16:37 ` Logan Gunthorpe
2018-03-21 17:40 ` [PATCH v13 00/10] Add io{read|write}64 to io-64-atomic headers Andy Shevchenko
2018-03-21 17:40 ` Andy Shevchenko
2018-03-21 19:47 ` Logan Gunthorpe
2018-03-21 19:47 ` Logan Gunthorpe
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=726eb143-2cca-b221-b569-e193a962e357@deltatee.com \
--to=logang@deltatee.com \
--cc=andy.shevchenko@gmail.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=horia.geanta@nxp.com \
--cc=kstewart@linuxfoundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ntb@googlegroups.com \
--cc=luc.vanoostenryck@gmail.com \
--cc=pombredanne@nexb.com \
--cc=tglx@linutronix.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