From: Krzysztof Kozlowski <krzk@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Rich Felker <dalias@libc.org>, Jiri Slaby <jirislaby@gmail.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
David Airlie <airlied@linux.ie>,
ML nouveau <nouveau@lists.freedesktop.org>,
Jason Wang <jasowang@redhat.com>,
DRI Development <dri-devel@lists.freedesktop.org>,
virtualization@lists.linux-foundation.org,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
Paul Mackerras <paulus@samba.org>,
Linux-Arch <linux-arch@vger.kernel.org>,
Dave Jiang <dave.jiang@intel.com>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Helge Deller <deller@gmx.de>,
Linux-sh list <linux-sh@vger.kernel.org>,
Alexey Brodkin <abrodkin@synopsys.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Ben Skeggs <bskeggs@redhat.com>, Dave Airlie <airlied@redhat.com>,
Matt Turner <mattst88@gmail.com>,
arcml <linux-snps-arc@lists.infradead.org>,
Nick Kossifidis <mickflemm@gmail.com>,
Allen Hubbe <allenbh@gmail.com>, Jon Mason <jdmason@kudzu.us>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Thomas Gleixner <tglx@linutronix.de>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Kalle Valo <kvalo@codeaurora.org>,
Richard Henderson <rth@twiddle.net>,
Christophe Leroy <christophe.leroy@c-s.fr>,
Parisc List <linux-parisc@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Vineet Gupta <vgupta@synopsys.com>,
alpha <linux-alpha@vger.kernel.org>,
linux-ntb@googlegroups.com,
Andrew Morton <akpm@linux-foundation.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
Date: Wed, 8 Jan 2020 10:15:49 +0100 [thread overview]
Message-ID: <20200108091549.GB10145@pi3> (raw)
In-Reply-To: <CAK8P3a21yPrmp4ik3Ei1BZfeqZNf0wL5NZNF3uXqb4FLRDyUPw@mail.gmail.com>
On Wed, Jan 08, 2020 at 09:44:36AM +0100, Arnd Bergmann wrote:
> On Wed, Jan 8, 2020 at 9:36 AM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> > Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
> > > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > I'll add to this one also changes to ioreadX_rep() and add another
> > > patch for volatile for reads and writes. I guess your review will be
> > > appreciated once more because of ioreadX_rep()
> > >
> >
> > volatile should really only be used where deemed necessary:
> >
> > https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html
> >
> > It is said: " ... accessor functions might use volatile on
> > architectures where direct I/O memory access does work. Essentially,
> > each accessor call becomes a little critical section on its own and
> > ensures that the access happens as expected by the programmer."
>
> The I/O accessors are one of the few places in which 'volatile' generally
> makes sense, at least for the implementations that do a plain pointer
> dereference (probably none of the ones in question here).
>
> In case of readl/writel, this is what we do in asm-generic:
>
> static inline u32 __raw_readl(const volatile void __iomem *addr)
> {
> return *(const volatile u32 __force *)addr;
> }
SuperH is another example:
1. ioread8_rep(void __iomem *addr, void *dst, unsigned long count)
calls mmio_insb()
2. static inline void mmio_insb(void __iomem *addr, u8 *dst, int count)
calls __raw_readb()
3. #define __raw_readb(a) (__chk_io_ptr(a), *(volatile u8 __force *)(a))
Even if interface was not marked as volatile, in fact its implementation
was casting to volatile.
> The __force-cast that removes the __iomem here also means that
> the 'volatile' keyword could be dropped from the argument list,
> as it has no real effect any more, but then there are a few drivers
> that mark their iomem pointers as either 'volatile void __iomem*' or
> (worse) 'volatile void *', so we keep it in the argument list to not
> add warnings for those drivers.
>
> It may be time to change these drivers to not use volatile for __iomem
> pointers, but that seems out of scope for what Krzysztof is trying
> to do. Ideally we would be consistent here though, either using volatile
> all the time or never.
Indeed. I guess there are no objections around const so let me send v2
for const only.
Best regards,
Krzysztof
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-01-08 9:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-07 16:52 [RFT 00/13] iomap: Constify ioreadX() iomem argument Krzysztof Kozlowski
2020-01-07 16:52 ` [RFT 01/13] iomap: Constify ioreadX() iomem argument (as in generic implementation) Krzysztof Kozlowski
2020-01-07 16:52 ` [RFT 02/13] alpha: " Krzysztof Kozlowski
2020-01-08 8:10 ` Geert Uytterhoeven
2020-01-08 9:07 ` Krzysztof Kozlowski
2020-01-07 16:53 ` [RFT 02/13] sh: " Krzysztof Kozlowski
2020-01-07 16:53 ` [RFT 03/13] alpha: " Krzysztof Kozlowski
2020-01-07 16:53 ` [RFT 03/13] sh: " Krzysztof Kozlowski
2020-01-07 17:08 ` Arnd Bergmann
2020-01-07 16:53 ` [RFT 04/13] parisc: " Krzysztof Kozlowski
2020-01-07 16:53 ` [RFT 05/13] powerpc: " Krzysztof Kozlowski
2020-01-07 16:53 ` [RFT 06/13] arc: " Krzysztof Kozlowski
2020-01-07 17:10 ` Arnd Bergmann
2020-01-07 16:53 ` [RFT 07/13] drm/mgag200: " Krzysztof Kozlowski
2020-01-07 16:53 ` [RFT 08/13] drm/nouveau: " Krzysztof Kozlowski
2020-01-07 16:53 ` [RFT 09/13] media: fsl-viu: " Krzysztof Kozlowski
2020-01-07 16:53 ` [RFT 10/13] net: wireless: ath5k: " Krzysztof Kozlowski
2020-01-07 16:53 ` [RFT 11/13] net: wireless: rtl818x: " Krzysztof Kozlowski
2020-01-07 16:53 ` [RFT 12/13] ntb: intel: " Krzysztof Kozlowski
2020-01-07 16:53 ` [RFT 13/13] virtio: pci: " Krzysztof Kozlowski
2020-01-08 8:07 ` [RFT 00/13] iomap: Constify ioreadX() iomem argument Geert Uytterhoeven
2020-01-08 8:12 ` Geert Uytterhoeven
2020-01-08 8:18 ` Krzysztof Kozlowski
2020-01-08 8:35 ` Christophe Leroy
2020-01-08 8:43 ` Geert Uytterhoeven
2020-01-08 8:48 ` Christophe Leroy
2020-01-08 17:39 ` David Laight
2020-01-08 8:44 ` Arnd Bergmann
2020-01-08 9:15 ` Krzysztof Kozlowski [this message]
2020-01-08 11:55 ` Arnd Bergmann
2020-01-08 8:15 ` Krzysztof Kozlowski
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=20200108091549.GB10145@pi3 \
--to=krzk@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=abrodkin@synopsys.com \
--cc=airlied@linux.ie \
--cc=airlied@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=allenbh@gmail.com \
--cc=arnd@arndb.de \
--cc=bskeggs@redhat.com \
--cc=christophe.leroy@c-s.fr \
--cc=dalias@libc.org \
--cc=dave.jiang@intel.com \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=geert@linux-m68k.org \
--cc=ink@jurassic.park.msu.ru \
--cc=jasowang@redhat.com \
--cc=jdmason@kudzu.us \
--cc=jirislaby@gmail.com \
--cc=kvalo@codeaurora.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-ntb@googlegroups.com \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mattst88@gmail.com \
--cc=mcgrof@kernel.org \
--cc=mchehab@kernel.org \
--cc=mickflemm@gmail.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=paulus@samba.org \
--cc=rth@twiddle.net \
--cc=tglx@linutronix.de \
--cc=vgupta@synopsys.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=ysato@users.sourceforge.jp \
/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).