linux-m68k.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 5/5] m68knommu: fix use of cpu_to_le() on IO access
@ 2020-06-15  7:16 Greg Ungerer
  2020-06-15 16:55 ` Luc Van Oostenryck
  0 siblings, 1 reply; 2+ messages in thread
From: Greg Ungerer @ 2020-06-15  7:16 UTC (permalink / raw)
  To: linux-m68k
  Cc: Greg Ungerer, kernel test robot, Marc Kleine-Budde, Luc Van Oostenryck

Due to the different data endian requirements of different buses on
m68knommu variants we sometimes need to byte swap results for readX()
or values to writeX(). Currently the code uses cpu_to_le to do this,
resulting in sparse warnings like:

arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32

Some casting to force __le32 types would resolve but it looks to be
simpler to just switch to using the underlying swab32() to resolve.

Similarly handle the 16bit cases in these functions as well.

Reported-by: kernel test robot <lkp@intel.com>
CC: Marc Kleine-Budde <mkl@pengutronix.de>
CC: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
 arch/m68k/include/asm/io_no.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 1bc739f1f1ad..2c96e8480173 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -67,7 +67,7 @@ static inline u16 readw(const volatile void __iomem *addr)
 {
 	if (cf_internalio(addr))
 		return __raw_readw(addr);
-	return __le16_to_cpu(__raw_readw(addr));
+	return swab16(__raw_readw(addr));
 }
 
 #define readl readl
@@ -75,7 +75,7 @@ static inline u32 readl(const volatile void __iomem *addr)
 {
 	if (cf_internalio(addr))
 		return __raw_readl(addr);
-	return __le32_to_cpu(__raw_readl(addr));
+	return swab32(__raw_readl(addr));
 }
 
 #define writew writew
@@ -84,7 +84,7 @@ static inline void writew(u16 value, volatile void __iomem *addr)
 	if (cf_internalio(addr))
 		__raw_writew(value, addr);
 	else
-		__raw_writew(__cpu_to_le16(value), addr);
+		__raw_writew(swab16(value), addr);
 }
 
 #define writel writel
@@ -93,7 +93,7 @@ static inline void writel(u32 value, volatile void __iomem *addr)
 	if (cf_internalio(addr))
 		__raw_writel(value, addr);
 	else
-		__raw_writel(__cpu_to_le32(value), addr);
+		__raw_writel(swab32(value), addr);
 }
 
 #else
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH 5/5] m68knommu: fix use of cpu_to_le() on IO access
  2020-06-15  7:16 [PATCH 5/5] m68knommu: fix use of cpu_to_le() on IO access Greg Ungerer
@ 2020-06-15 16:55 ` Luc Van Oostenryck
  0 siblings, 0 replies; 2+ messages in thread
From: Luc Van Oostenryck @ 2020-06-15 16:55 UTC (permalink / raw)
  To: Greg Ungerer; +Cc: linux-m68k, kernel test robot, Marc Kleine-Budde

On Mon, Jun 15, 2020 at 05:16:36PM +1000, Greg Ungerer wrote:
> Due to the different data endian requirements of different buses on
> m68knommu variants we sometimes need to byte swap results for readX()
> or values to writeX(). Currently the code uses cpu_to_le to do this,
> resulting in sparse warnings like:
> 
> arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32
> 
> Some casting to force __le32 types would resolve but it looks to be
> simpler to just switch to using the underlying swab32() to resolve.

Yes indeed, since the raw accessors are supposed to be native-endian, doing:
	native -> force cast to le32 -> le32_to_cpu() 
doesn't seem to have any advantages over the swab32().

Feel free to add my:
Reviewed-y: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>

-- Luc

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-06-15 16:55 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-15  7:16 [PATCH 5/5] m68knommu: fix use of cpu_to_le() on IO access Greg Ungerer
2020-06-15 16:55 ` Luc Van Oostenryck

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).