Hi Christophe,
On Wed, Jan 8, 2020 at 9:35 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:
On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski krzk@kernel.org 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@glider.be
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.h...
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