Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
Hi Krzysztof,
On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski 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.
> Patchset was really tested on all affected architectures.
> Build testing is in progress - I hope auto-builders will point any issues.
>
>
> Todo
>
> Convert also string versions (ioread16_rep() etc) if this aproach looks OK.
>
>
> Merging
> ===
> The first 5 patches - iomap, alpha, sh, parisc and powerpc - should probably
> go
> via one tree, or even squashed into one.
Yes, they should be squashed, cfr. Arnd's comment.
I also wouldn't bother doing the updates in patches 6-10.
The rest looks good to me.
Thanks a lot!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFT 02/13] alpha: Constify ioreadX() iomem argument (as in generic implementation)
Hi Krzysztof,
On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote:
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be converted to a "const" version for const-safety and
> consistency among architectures.
>
> Signed-off-by: Krzysztof Kozlowski
> --- a/arch/alpha/include/asm/io.h
> +++ b/arch/alpha/include/asm/io.h
> @@ -151,9 +151,9 @@ static inline void generic_##NAME(TYPE b, QUAL void
> __iomem *addr) \
> alpha_mv.mv_##NAME(b, addr);\
> }
>
> -REMAP1(unsigned int, ioread8, /**/)
> -REMAP1(unsigned int, ioread16, /**/)
> -REMAP1(unsigned int, ioread32, /**/)
> +REMAP1(unsigned int, ioread8, const)
> +REMAP1(unsigned int, ioread16, const)
> +REMAP1(unsigned int, ioread32, const)
If these would become "const volatile", there would no longer be a need
for the last parameter of the REMAP1() macro.
> REMAP1(u8, readb, const volatile)
> REMAP1(u16, readw, const volatile)
> REMAP1(u32, readl, const volatile)
Same for REMAP2() macro below, for iowrite*().
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
Hi Krzysztof,
On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven wrote:
> On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski 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
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
On Wed, 8 Jan 2020 at 09:08, Geert Uytterhoeven wrote: > > Hi Krzysztof, > > On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski 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. It's kind of separate issue although I could squash it to limit redundant changes. > > Patchset was really tested on all affected architectures. I just spot an error in my first message. I wanted to say: "Patchset was NOT really tested on all affected architectures." Obviously. > > Build testing is in progress - I hope auto-builders will point any issues. > > > > > > Todo > > > > Convert also string versions (ioread16_rep() etc) if this aproach looks OK. > > > > > > Merging > > === > > The first 5 patches - iomap, alpha, sh, parisc and powerpc - should > > probably go > > via one tree, or even squashed into one. > > Yes, they should be squashed, cfr. Arnd's comment. > I also wouldn't bother doing the updates in patches 6-10. Indeed, thanks for comments. Best regards, Krzysztof ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote: > > Hi Krzysztof, > > On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven > wrote: > > On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski 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 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() Thanks, Krzysztof ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit : On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote: Hi Krzysztof, On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven wrote: On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski 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 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." Christophe ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
Hi Christophe,
On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy wrote:
> Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
> > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven
> > wrote:
> >> On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven
> >> wrote:
> >>> On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski
> >>> 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
> >
> > 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 -- ge...@linux-m68k.org
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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
On Wed, Jan 8, 2020 at 9:36 AM Christophe Leroy wrote:
> Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
> > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven
> > 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;
}
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.
Arnd
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
Hi Geert, Le 08/01/2020 à 09:43, Geert Uytterhoeven a écrit : Hi Christophe, On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy wrote: Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit : On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote: On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven wrote: On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski 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 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? My point was: it might be necessary for some arches and not for others. And as pointed by Arnd, the volatile is really only necessary for the dereference itself, should the arch use dereferencing. So I guess the best would be to go in the other direction: remove volatile keyword wherever possible instead of adding it where it is not needed. Christophe ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFT 02/13] alpha: Constify ioreadX() iomem argument (as in generic implementation)
On Wed, Jan 08, 2020 at 09:10:06AM +0100, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote: > > The ioreadX() helpers have inconsistent interface. On some architectures > > void *__iomem address argument is a pointer to const, on some not. > > > > Implementations of ioreadX() do not modify the memory under the address > > so they can be converted to a "const" version for const-safety and > > consistency among architectures. > > > > Signed-off-by: Krzysztof Kozlowski > > > --- a/arch/alpha/include/asm/io.h > > +++ b/arch/alpha/include/asm/io.h > > @@ -151,9 +151,9 @@ static inline void generic_##NAME(TYPE b, QUAL void > > __iomem *addr) \ > > alpha_mv.mv_##NAME(b, addr);\ > > } > > > > -REMAP1(unsigned int, ioread8, /**/) > > -REMAP1(unsigned int, ioread16, /**/) > > -REMAP1(unsigned int, ioread32, /**/) > > +REMAP1(unsigned int, ioread8, const) > > +REMAP1(unsigned int, ioread16, const) > > +REMAP1(unsigned int, ioread32, const) > > If these would become "const volatile", there would no longer be a need > for the last parameter of the REMAP1() macro. > > > REMAP1(u8, readb, const volatile) > > REMAP1(u16, readw, const volatile) > > REMAP1(u32, readl, const volatile) > > Same for REMAP2() macro below, for iowrite*(). Good point, thanks! Best regards, Krzysztof ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
On Wed, Jan 08, 2020 at 09:44:36AM +0100, Arnd Bergmann wrote:
> On Wed, Jan 8, 2020 at 9:36 AM Christophe Leroy
> wrote:
> > Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
> > > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven
> > > 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
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
On Wed, Jan 8, 2020 at 10:15 AM Krzysztof Kozlowski wrote: > > 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. Ok, sounds good. Maybe mention in the changelog then that the 'volatile' in the interface is intentionally left out, and that only users of readl/writel still have it to deal with existing drivers. Arnd ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [RFT 00/13] iomap: Constify ioreadX() iomem argument
From: Christophe Leroy > Sent: 08 January 2020 08:49 ... > And as pointed by Arnd, the volatile is really only necessary for the > dereference itself, should the arch use dereferencing. I've had trouble with some versions of gcc and reading of 'volatile unsigned char *'. It tended to follow the memory read with an extra mask with 0xff. (I suspect that internally the value landed into a temporary 'int' variable.) I got better code using memory barriers. So putting an asm barrier for the exact location of the memory read either side of the read should have the desired effect without adding extra instructions. (You might think 'volatile' would mean that - but it doesn't.) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 2/9] net: wireless: rtl818x: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
1. Add Geert's review.
---
drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
index 7948a2da195a..2ff00800d45b 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
@@ -150,17 +150,17 @@ void rtl8180_write_phy(struct ieee80211_hw *dev, u8 addr,
u32 data);
void rtl8180_set_anaparam(struct rtl8180_priv *priv, u32 anaparam);
void rtl8180_set_anaparam2(struct rtl8180_priv *priv, u32 anaparam2);
-static inline u8 rtl818x_ioread8(struct rtl8180_priv *priv, u8 __iomem *addr)
+static inline u8 rtl818x_ioread8(struct rtl8180_priv *priv, const u8 __iomem
*addr)
{
return ioread8(addr);
}
-static inline u16 rtl818x_ioread16(struct rtl8180_priv *priv, __le16 __iomem
*addr)
+static inline u16 rtl818x_ioread16(struct rtl8180_priv *priv, const __le16
__iomem *addr)
{
return ioread16(addr);
}
-static inline u32 rtl818x_ioread32(struct rtl8180_priv *priv, __le32 __iomem
*addr)
+static inline u32 rtl818x_ioread32(struct rtl8180_priv *priv, const __le32
__iomem *addr)
{
return ioread32(addr);
}
--
2.17.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 0/9] iomap: Constify ioreadX() iomem argument
Hi, Changes since v1 https://lore.kernel.org/lkml/1578415992-24054-1-git-send-email-k...@kernel.org/ 1. Constify also ioreadX_rep() and mmio_insX(), 2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability, 3. Add Geert's review, 4. Re-order patches so all optional driver changes are at the end. Description === 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. Patchset was not really tested on all affected architectures. Build testing is in progress - I hope auto-builders will point any issues. volatile There is still interface inconsistency between architectures around "volatile" qualifier: - include/asm-generic/io.h:static inline u32 ioread32(const volatile void __iomem *addr) - include/asm-generic/iomap.h:extern unsigned int ioread32(const void __iomem *); This is still discussed and out of scope of this patchset. Merging === Multiple architectures are affected in first patch so acks are welcomed. Patches 2-4 depend on first patch. The rest is optional cleanup, without actual impact. Best regards, Krzysztof Krzysztof Kozlowski (9): iomap: Constify ioreadX() iomem argument (as in generic implementation) net: wireless: rtl818x: Constify ioreadX() iomem argument (as in generic implementation) ntb: intel: Constify ioreadX() iomem argument (as in generic implementation) virtio: pci: Constify ioreadX() iomem argument (as in generic implementation) arc: Constify ioreadX() iomem argument (as in generic implementation) drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation) drm/nouveau: Constify ioreadX() iomem argument (as in generic implementation) media: fsl-viu: Constify ioreadX() iomem argument (as in generic implementation) net: wireless: ath5k: Constify ioreadX() iomem argument (as in generic implementation) arch/alpha/include/asm/core_apecs.h | 6 +- arch/alpha/include/asm/core_cia.h | 6 +- arch/alpha/include/asm/core_lca.h | 6 +- arch/alpha/include/asm/core_marvel.h | 4 +- arch/alpha/include/asm/core_mcpcia.h | 6 +- arch/alpha/include/asm/core_t2.h | 2 +- arch/alpha/include/asm/io.h | 12 ++-- arch/alpha/include/asm/io_trivial.h | 16 ++--- arch/alpha/include/asm/jensen.h | 2 +- arch/alpha/include/asm/machvec.h | 6 +- arch/alpha/kernel/core_marvel.c | 2 +- arch/alpha/kernel/io.c| 12 ++-- arch/arc/plat-axs10x/axs10x.c | 4 +- arch/parisc/include/asm/io.h | 4 +- arch/parisc/lib/iomap.c | 72 +-- arch/powerpc/kernel/iomap.c | 28 arch/sh/kernel/iomap.c| 22 +++--- drivers/gpu/drm/mgag200/mgag200_drv.h | 4 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +- drivers/media/platform/fsl-viu.c | 2 +- drivers/net/wireless/ath/ath5k/ahb.c | 10 +-- .../realtek/rtl818x/rtl8180/rtl8180.h | 6 +- drivers/ntb/hw/intel/ntb_hw_gen1.c| 2 +- drivers/ntb/hw/intel/ntb_hw_gen3.h| 2 +- drivers/ntb/hw/intel/ntb_hw_intel.h | 2 +- drivers/virtio/virtio_pci_modern.c| 6 +- include/asm-generic/iomap.h | 28 include/linux/io-64-nonatomic-hi-lo.h | 4 +- include/linux/io-64-nonatomic-lo-hi.h | 4 +- lib/iomap.c | 30 30 files changed, 156 insertions(+), 156 deletions(-) -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 1/9] iomap: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On
some architectures void *__iomem address argument is a pointer to const,
on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Suggested-by: Geert Uytterhoeven
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
1. Constify also ioreadX_rep() and mmio_insX(),
2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability,
3. Add Geert's review.
---
arch/alpha/include/asm/core_apecs.h | 6 +--
arch/alpha/include/asm/core_cia.h | 6 +--
arch/alpha/include/asm/core_lca.h | 6 +--
arch/alpha/include/asm/core_marvel.h | 4 +-
arch/alpha/include/asm/core_mcpcia.h | 6 +--
arch/alpha/include/asm/core_t2.h | 2 +-
arch/alpha/include/asm/io.h | 12 ++---
arch/alpha/include/asm/io_trivial.h | 16 +++---
arch/alpha/include/asm/jensen.h | 2 +-
arch/alpha/include/asm/machvec.h | 6 +--
arch/alpha/kernel/core_marvel.c | 2 +-
arch/alpha/kernel/io.c| 12 ++---
arch/parisc/include/asm/io.h | 4 +-
arch/parisc/lib/iomap.c | 72 +--
arch/powerpc/kernel/iomap.c | 28 +--
arch/sh/kernel/iomap.c| 22
include/asm-generic/iomap.h | 28 +--
include/linux/io-64-nonatomic-hi-lo.h | 4 +-
include/linux/io-64-nonatomic-lo-hi.h | 4 +-
lib/iomap.c | 30 +--
20 files changed, 136 insertions(+), 136 deletions(-)
diff --git a/arch/alpha/include/asm/core_apecs.h
b/arch/alpha/include/asm/core_apecs.h
index 0a07055bc0fe..2d9726fc02ef 100644
--- a/arch/alpha/include/asm/core_apecs.h
+++ b/arch/alpha/include/asm/core_apecs.h
@@ -384,7 +384,7 @@ struct el_apecs_procdata
} \
} while (0)
-__EXTERN_INLINE unsigned int apecs_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread8(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -420,7 +420,7 @@ __EXTERN_INLINE void apecs_iowrite8(u8 b, void __iomem
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int apecs_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread16(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -456,7 +456,7 @@ __EXTERN_INLINE void apecs_iowrite16(u16 b, void __iomem
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int apecs_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread32(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
if (addr < APECS_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_cia.h
b/arch/alpha/include/asm/core_cia.h
index c706a7f2b061..cb22991f6761 100644
--- a/arch/alpha/include/asm/core_cia.h
+++ b/arch/alpha/include/asm/core_cia.h
@@ -342,7 +342,7 @@ struct el_CIA_sysdata_mcheck {
#define vuip volatile unsigned int __force *
#define vulp volatile unsigned long __force *
-__EXTERN_INLINE unsigned int cia_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread8(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -374,7 +374,7 @@ __EXTERN_INLINE void cia_iowrite8(u8 b, void __iomem *xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int cia_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread16(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -404,7 +404,7 @@ __EXTERN_INLINE void cia_iowrite16(u16 b, void __iomem
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int cia_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread32(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
if (addr < CIA_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_lca.h
b/arch/alpha/include/asm/core_lca.h
index 84d5e5b84f4f..ec86314418cb 100644
--- a/arch/alpha/include/asm/core_lca.h
+++ b/arch/alpha/include/asm/core_lca.h
@@ -230,7 +230,7 @@ union el_lca {
} while (0)
-__EXTERN_INLINE unsigned int lca_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int lca_ioread8(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -266,7 +266,7 @@ __EXTERN_INLINE void lca_iowrite8(u8 b, void __iomem *xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int lca_ioread1
[PATCH v2 7/9] drm/nouveau: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski --- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index f8015e0318d7..5120d062c2df 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -613,7 +613,7 @@ nouveau_bo_rd32(struct nouveau_bo *nvbo, unsigned index) mem += index; if (is_iomem) - return ioread32_native((void __force __iomem *)mem); + return ioread32_native((const void __force __iomem *)mem); else return *mem; } -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 6/9] drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski --- drivers/gpu/drm/mgag200/mgag200_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h index aa32aad222c2..6512b3af4fb7 100644 --- a/drivers/gpu/drm/mgag200/mgag200_drv.h +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h @@ -34,9 +34,9 @@ #define MGAG200FB_CONN_LIMIT 1 -#define RREG8(reg) ioread8(((void __iomem *)mdev->rmmio) + (reg)) +#define RREG8(reg) ioread8(((const void __iomem *)mdev->rmmio) + (reg)) #define WREG8(reg, v) iowrite8(v, ((void __iomem *)mdev->rmmio) + (reg)) -#define RREG32(reg) ioread32(((void __iomem *)mdev->rmmio) + (reg)) +#define RREG32(reg) ioread32(((const void __iomem *)mdev->rmmio) + (reg)) #define WREG32(reg, v) iowrite32(v, ((void __iomem *)mdev->rmmio) + (reg)) #define ATTR_INDEX 0x1fc0 -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 8/9] media: fsl-viu: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski --- drivers/media/platform/fsl-viu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c index 81a8faedbba6..991d9dc82749 100644 --- a/drivers/media/platform/fsl-viu.c +++ b/drivers/media/platform/fsl-viu.c @@ -34,7 +34,7 @@ /* Allow building this driver with COMPILE_TEST */ #if !defined(CONFIG_PPC) && !defined(CONFIG_MICROBLAZE) #define out_be32(v, a) iowrite32be(a, (void __iomem *)v) -#define in_be32(a) ioread32be((void __iomem *)a) +#define in_be32(a) ioread32be((const void __iomem *)a) #endif #define BUFFER_TIMEOUT msecs_to_jiffies(500) /* 0.5 seconds */ -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 4/9] virtio: pci: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
1. Add Geert's review.
---
drivers/virtio/virtio_pci_modern.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_pci_modern.c
b/drivers/virtio/virtio_pci_modern.c
index 7abcc50838b8..fc58db4ab6c3 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -26,16 +26,16 @@
* method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses
* for 16-bit fields and 8-bit accesses for 8-bit fields.
*/
-static inline u8 vp_ioread8(u8 __iomem *addr)
+static inline u8 vp_ioread8(const u8 __iomem *addr)
{
return ioread8(addr);
}
-static inline u16 vp_ioread16 (__le16 __iomem *addr)
+static inline u16 vp_ioread16 (const __le16 __iomem *addr)
{
return ioread16(addr);
}
-static inline u32 vp_ioread32(__le32 __iomem *addr)
+static inline u32 vp_ioread32(const __le32 __iomem *addr)
{
return ioread32(addr);
}
--
2.17.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 5/9] arc: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the
address so they can be converted to a "const" version for const-safety
and consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
---
arch/arc/plat-axs10x/axs10x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c
index 63ea5a606ecd..180c260a8221 100644
--- a/arch/arc/plat-axs10x/axs10x.c
+++ b/arch/arc/plat-axs10x/axs10x.c
@@ -84,7 +84,7 @@ static void __init axs10x_print_board_ver(unsigned int creg,
const char *str)
unsigned int val;
} board;
- board.val = ioread32((void __iomem *)creg);
+ board.val = ioread32((const void __iomem *)creg);
pr_info("AXS: %s FPGA Date: %u-%u-%u\n", str, board.d, board.m,
board.y);
}
@@ -95,7 +95,7 @@ static void __init axs10x_early_init(void)
char mb[32];
/* Determine motherboard version */
- if (ioread32((void __iomem *) CREG_MB_CONFIG) & (1 << 28))
+ if (ioread32((const void __iomem *) CREG_MB_CONFIG) & (1 << 28))
mb_rev = 3; /* HT-3 (rev3.0) */
else
mb_rev = 2; /* HT-2 (rev2.0) */
--
2.17.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 9/9] net: wireless: ath5k: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
---
drivers/net/wireless/ath/ath5k/ahb.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ahb.c
b/drivers/net/wireless/ath/ath5k/ahb.c
index 2c9cec8b53d9..8bd01df369fb 100644
--- a/drivers/net/wireless/ath/ath5k/ahb.c
+++ b/drivers/net/wireless/ath/ath5k/ahb.c
@@ -138,18 +138,18 @@ static int ath_ahb_probe(struct platform_device *pdev)
if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
/* Enable WMAC AHB arbitration */
- reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
+ reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
reg |= AR5K_AR2315_AHB_ARB_CTL_WLAN;
iowrite32(reg, (void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
/* Enable global WMAC swapping */
- reg = ioread32((void __iomem *) AR5K_AR2315_BYTESWAP);
+ reg = ioread32((const void __iomem *) AR5K_AR2315_BYTESWAP);
reg |= AR5K_AR2315_BYTESWAP_WMAC;
iowrite32(reg, (void __iomem *) AR5K_AR2315_BYTESWAP);
} else {
/* Enable WMAC DMA access (assuming 5312 or 231x*/
/* TODO: check other platforms */
- reg = ioread32((void __iomem *) AR5K_AR5312_ENABLE);
+ reg = ioread32((const void __iomem *) AR5K_AR5312_ENABLE);
if (to_platform_device(ah->dev)->id == 0)
reg |= AR5K_AR5312_ENABLE_WLAN0;
else
@@ -202,12 +202,12 @@ static int ath_ahb_remove(struct platform_device *pdev)
if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
/* Disable WMAC AHB arbitration */
- reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
+ reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
reg &= ~AR5K_AR2315_AHB_ARB_CTL_WLAN;
iowrite32(reg, (void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
} else {
/*Stop DMA access */
- reg = ioread32((void __iomem *) AR5K_AR5312_ENABLE);
+ reg = ioread32((const void __iomem *) AR5K_AR5312_ENABLE);
if (to_platform_device(ah->dev)->id == 0)
reg &= ~AR5K_AR5312_ENABLE_WLAN0;
else
--
2.17.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 3/9] ntb: intel: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
1. Add Geert's review.
---
drivers/ntb/hw/intel/ntb_hw_gen1.c | 2 +-
drivers/ntb/hw/intel/ntb_hw_gen3.h | 2 +-
drivers/ntb/hw/intel/ntb_hw_intel.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen1.c
b/drivers/ntb/hw/intel/ntb_hw_gen1.c
index bb57ec239029..9202502a9787 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen1.c
+++ b/drivers/ntb/hw/intel/ntb_hw_gen1.c
@@ -1202,7 +1202,7 @@ int intel_ntb_peer_spad_write(struct ntb_dev *ntb, int
pidx, int sidx,
ndev->peer_reg->spad);
}
-static u64 xeon_db_ioread(void __iomem *mmio)
+static u64 xeon_db_ioread(const void __iomem *mmio)
{
return (u64)ioread16(mmio);
}
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen3.h
b/drivers/ntb/hw/intel/ntb_hw_gen3.h
index 75fb86ca27bb..d1455f24ec99 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen3.h
+++ b/drivers/ntb/hw/intel/ntb_hw_gen3.h
@@ -91,7 +91,7 @@
#define GEN3_DB_TOTAL_SHIFT33
#define GEN3_SPAD_COUNT16
-static inline u64 gen3_db_ioread(void __iomem *mmio)
+static inline u64 gen3_db_ioread(const void __iomem *mmio)
{
return ioread64(mmio);
}
diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.h
b/drivers/ntb/hw/intel/ntb_hw_intel.h
index e071e28bca3f..3c0a5a2da241 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.h
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.h
@@ -102,7 +102,7 @@ struct intel_ntb_dev;
struct intel_ntb_reg {
int (*poll_link)(struct intel_ntb_dev *ndev);
int (*link_is_up)(struct intel_ntb_dev *ndev);
- u64 (*db_ioread)(void __iomem *mmio);
+ u64 (*db_ioread)(const void __iomem *mmio);
void (*db_iowrite)(u64 db_bits, void __iomem *mmio);
unsigned long ntb_ctl;
resource_size_t db_size;
--
2.17.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 3/9] ntb: intel: Constify ioreadX() iomem argument (as in generic implementation)
On 1/8/20 1:05 PM, Krzysztof Kozlowski wrote:
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
Acked-by: Dave Jiang
---
Changes since v1:
1. Add Geert's review.
---
drivers/ntb/hw/intel/ntb_hw_gen1.c | 2 +-
drivers/ntb/hw/intel/ntb_hw_gen3.h | 2 +-
drivers/ntb/hw/intel/ntb_hw_intel.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen1.c
b/drivers/ntb/hw/intel/ntb_hw_gen1.c
index bb57ec239029..9202502a9787 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen1.c
+++ b/drivers/ntb/hw/intel/ntb_hw_gen1.c
@@ -1202,7 +1202,7 @@ int intel_ntb_peer_spad_write(struct ntb_dev *ntb, int
pidx, int sidx,
ndev->peer_reg->spad);
}
-static u64 xeon_db_ioread(void __iomem *mmio)
+static u64 xeon_db_ioread(const void __iomem *mmio)
{
return (u64)ioread16(mmio);
}
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen3.h
b/drivers/ntb/hw/intel/ntb_hw_gen3.h
index 75fb86ca27bb..d1455f24ec99 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen3.h
+++ b/drivers/ntb/hw/intel/ntb_hw_gen3.h
@@ -91,7 +91,7 @@
#define GEN3_DB_TOTAL_SHIFT 33
#define GEN3_SPAD_COUNT 16
-static inline u64 gen3_db_ioread(void __iomem *mmio)
+static inline u64 gen3_db_ioread(const void __iomem *mmio)
{
return ioread64(mmio);
}
diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.h
b/drivers/ntb/hw/intel/ntb_hw_intel.h
index e071e28bca3f..3c0a5a2da241 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.h
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.h
@@ -102,7 +102,7 @@ struct intel_ntb_dev;
struct intel_ntb_reg {
int (*poll_link)(struct intel_ntb_dev *ndev);
int (*link_is_up)(struct intel_ntb_dev *ndev);
- u64 (*db_ioread)(void __iomem *mmio);
+ u64 (*db_ioread)(const void __iomem *mmio);
void (*db_iowrite)(u64 db_bits, void __iomem *mmio);
unsigned long ntb_ctl;
resource_size_t db_size;
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 1/9] iomap: Constify ioreadX() iomem argument (as in generic implementation)
On Wed, Jan 8, 2020 at 9:05 PM Krzysztof Kozlowski wrote: > > The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On > some architectures void *__iomem address argument is a pointer to const, > on some not. > > Implementations of ioreadX() do not modify the memory under the address > so they can be converted to a "const" version for const-safety and > consistency among architectures. > > Suggested-by: Geert Uytterhoeven > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Geert Uytterhoeven Thanks for getting this done! Reviewed-by: Arnd Bergmann > Changes since v1: > 1. Constify also ioreadX_rep() and mmio_insX(), > 2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability, The alpha and parisc versions should be independent, I was thinking you leave them as separate patches, but this work for me too. I have no real opinion on the other 8 patches, I would have left them out completely, but they don't hurt either. Arnd ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 6/9] drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation)
Hi Am 08.01.20 um 21:05 schrieb Krzysztof Kozlowski: > The ioreadX() helpers have inconsistent interface. On some architectures > void *__iomem address argument is a pointer to const, on some not. > > Implementations of ioreadX() do not modify the memory under the address > so they can be converted to a "const" version for const-safety and > consistency among architectures. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Thomas Zimmermann > --- > drivers/gpu/drm/mgag200/mgag200_drv.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h > b/drivers/gpu/drm/mgag200/mgag200_drv.h > index aa32aad222c2..6512b3af4fb7 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_drv.h > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h > @@ -34,9 +34,9 @@ > > #define MGAG200FB_CONN_LIMIT 1 > > -#define RREG8(reg) ioread8(((void __iomem *)mdev->rmmio) + (reg)) > +#define RREG8(reg) ioread8(((const void __iomem *)mdev->rmmio) + (reg)) > #define WREG8(reg, v) iowrite8(v, ((void __iomem *)mdev->rmmio) + (reg)) > -#define RREG32(reg) ioread32(((void __iomem *)mdev->rmmio) + (reg)) > +#define RREG32(reg) ioread32(((const void __iomem *)mdev->rmmio) + (reg)) > #define WREG32(reg, v) iowrite32(v, ((void __iomem *)mdev->rmmio) + (reg)) > > #define ATTR_INDEX 0x1fc0 > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH v2 5/9] arc: Constify ioreadX() iomem argument (as in generic implementation)
Hi Krzysztof, > The ioreadX() helpers have inconsistent interface. On some architectures > void *__iomem address argument is a pointer to const, on some not. > > Implementations of ioreadX() do not modify the memory under the > address so they can be converted to a "const" version for const-safety > and consistency among architectures. Thanks for this clean-up. Looks good to me, so ... Acked-by: Alexey Brodkin ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
