SH: sh7785lcr board: restore big-endian operation.

As of 37b7a97884ba64bf7d403351ac2a9476ab4f1bba we have to use the endianess-agnostic I/O accessor functions.

Tested on both litte-endian and big-endian sh7785lcr.

---
 arch/sh/boards/board-sh7785lcr.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

index d879848..c4cb782 100644
@@ -339,7 +339,7 @@ static void __init sh7785lcr_setup(char **cmdline_p)
 		return;
 	}
 
-	writel(0x000307c2, sm501_reg + SM501_DRAM_CONTROL);
+	__raw_writel(0x000307c2, sm501_reg + SM501_DRAM_CONTROL);
 	iounmap(sm501_reg);
 }
 

1.7.4.1

As of 37b7a97884ba64bf7d403351ac2a9476ab4f1bba we have to use the endianess-agnostic I/O accessor functions.

Tested on both litte-endian and big-endian sh7785lcr.

---
 drivers/tty/serial/sh-sci.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

index aff9d61..0b45258 100644
@@ -332,9 +332,9 @@ static unsigned int sci_serial_in(struct uart_port *p, int offset)
 	struct plat_sci_reg *reg = sci_getreg(p, offset);
 
 	if (reg->size == 8)
-		return ioread8(p->membase + (reg->offset << p->regshift));
+		return __raw_readb(p->membase + (reg->offset << p->regshift));
 	else if (reg->size == 16)
-		return ioread16(p->membase + (reg->offset << p->regshift));
+		return __raw_readw(p->membase + (reg->offset << p->regshift));
 	else
 		WARN(1, "Invalid register access\n");
 

@@ -346,9 +346,9 @@ static void sci_serial_out(struct uart_port *p, int offset, int value)
 	struct plat_sci_reg *reg = sci_getreg(p, offset);
 
 	if (reg->size == 8)
-		iowrite8(value, p->membase + (reg->offset << p->regshift));
+		__raw_writeb(value, p->membase + (reg->offset << p->regshift));
 	else if (reg->size == 16)
-		iowrite16(value, p->membase + (reg->offset << p->regshift));
+		__raw_writew(value, p->membase + (reg->offset << p->regshift));
 	else
 		WARN(1, "Invalid register access\n");
 }

1.7.4.1

Please always put a human readable description of what the git id is, so that we have a chance to understand what is going on.

Are these patches supposed to be going through the sh tree, or the serial tree to Linus?

And watch your To: line, it seemed to be munged :(

confused,

greg k-h

Hi Greg!

First -- as you probably have guessed already -- I'm not (not yet?) :-) too familiar with the Linux kernel patch submission process. I have spent quite some time reading the included documentation, but apparently missed some details... :-)

Sorry. ``sh: machvec IO death.'' -- well, the essential part what I'm fixing here is that before this commit readw (and friends, such as ioread16) didn't do any endianess modification of the data, but directly invoked __raw_readw, whereas after 37b7a978 they do such modification by means of filtering through le16_to_cpu (in the readw/ioread16 case). This is where things break for big endian (but not little endian, where this is a no-op).

I'm assuming that Paul Mundt will handle the whole lot in an SH tree.

Paul, by the way, if that's more convenient I can also publish my Git tree.

Yes. By means of scripts/get_maintainer.pl (and some manual adjustments) I created the Cc: lists that are part of my commits' log messages. Then, I just had git send-email send that out, without explicitly specifying a primary recipient (To: line). I assume I should have put Paul there?

On this patch, the linux-serial was Cced (as suggested by scripts/get_maintainer.pl), as it touches a TTY/serial driver, and I wanted to make sure to give you an opportunity to review that the patch doesn't introduce any breakage on non-SH architectures, for example. (Despite its indicative name, sh-sci also seems to be used on some ARM boards.)

Sorry; will hopefully improve. :-)

Grüße,
Thomas

On SH, as of 37b7a97884ba64bf7d403351ac2a9476ab4f1bba we have to use the endianess-agnostic I/O accessor functions.

This driver is also enabled in ARM's viper_defconfig as well as MIPS' bcm47xx_defconfig and fuloong2e_defconfig -- I suppose none of these are operating in big-endian mode, or this issue should already have been noticed before.

The device is now recognized correctly for both litte-endian and big-endian sh7785lcr, but I have not tested this any further, as the board is situated in a remote data center.

---
 drivers/usb/host/r8a66597.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

index f28782d..c2ea6d1 100644
@@ -170,7 +170,7 @@ static inline struct urb *r8a66597_get_urb(struct r8a66597 *r8a66597,
 
 static inline u16 r8a66597_read(struct r8a66597 *r8a66597, unsigned long offset)
 {
-	return ioread16(r8a66597->reg + offset);
+	return __raw_readw(r8a66597->reg + offset);
 }
 
 static inline void r8a66597_read_fifo(struct r8a66597 *r8a66597,

@@ -198,7 +198,7 @@ static inline void r8a66597_read_fifo(struct r8a66597 *r8a66597,
 static inline void r8a66597_write(struct r8a66597 *r8a66597, u16 val,
 				  unsigned long offset)
 {
-	iowrite16(val, r8a66597->reg + offset);
+	__raw_writew(val, r8a66597->reg + offset);
 }
 
 static inline void r8a66597_mdfy(struct r8a66597 *r8a66597,

1.7.4.1

Hello.

Please also specify the summary of thta commit in parens.

WBR, Sergei

On SH, as of 37b7a97884ba64bf7d403351ac2a9476ab4f1bba we have to use the endianess-agnostic I/O accessor functions.

In commit bf5f0019046d596d613caf74722ba4994e153899, Heiko fixed this for 32-bit PowerPC; my patch now generalizes upon that.

The device is now recognized correctly for both litte-endian and big-endian sh7785lcr, but I have not tested this any further, as the board is situated in a remote data center.

---
 include/linux/sm501.h |    9 ++-------
 1 files changed, 2 insertions(+), 7 deletions(-)

index 02fde50..0312e3c 100644
@@ -173,10 +173,5 @@ struct sm501_platdata {
 	unsigned int			 gpio_i2c_nr;
 };
 
-#if defined(CONFIG_PPC32)
-#define smc501_readl(addr)		ioread32be((addr))
-#define smc501_writel(val, addr)	iowrite32be((val), (addr))
-#else
-#define smc501_readl(addr)		readl(addr)
-#define smc501_writel(val, addr)	writel(val, addr)
-#endif
+#define smc501_readl(addr)		__raw_readl(addr)
+#define smc501_writel(val, addr)	__raw_writel(val, addr)

1.7.4.1