Hi Christophe, On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy <christophe.leroy@xxxxxx> wrote: > Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit : > > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > >> On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > >>> On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: > >>>> The ioread8/16/32() and others have inconsistent interface among the > >>>> architectures: some taking address as const, some not. > >>>> > >>>> It seems there is nothing really stopping all of them to take > >>>> pointer to const. > >>> > >>> Shouldn't all of them take const volatile __iomem pointers? > >>> It seems the "volatile" is missing from all but the implementations in > >>> include/asm-generic/io.h. > >> > >> As my "volatile" comment applies to iowrite*(), too, probably that should be > >> done in a separate patch. > >> > >> Hence with patches 1-5 squashed, and for patches 11-13: > >> Reviewed-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> > > > > 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." That is exactly the use case here: all above are accessor functions. Why would ioreadX() not need volatile, while readY() does? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
