[PATCH] UPIO_TSI cleanup

[PATCH] UPIO_TSI cleanup

[Al Viro]

(le32_to_cpu(x) >> 8) & 0xff is a very odd way to spell (x >> 16) & 0xff,
even if that code is hit only on ppc.  The value is host-endian - we've
got it from readl(), after all...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
 drivers/serial/8250.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 0ae9ced..10c2daa 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -320,8 +320,8 @@ #endif
 
 	case UPIO_TSI:
 		if (offset == UART_IIR) {
-			tmp = readl((u32 *)(up->port.membase + UART_RX));
-			return (cpu_to_le32(tmp) >> 8) & 0xff;
+			tmp = readl(up->port.membase + (UART_IIR & ~3));
+			return (tmp >> 16) & 0xff; /* UART_IIR % 4 == 2 */
 		} else
 			return readb(up->port.membase + offset);
 
-- 
1.4.2.GIT

Re: [PATCH] UPIO_TSI cleanup

[Sergei Shtylyov]

Hello.

Al Viro wrote:
> (le32_to_cpu(x) >> 8) & 0xff is a very odd way to spell (x >> 16) & 0xff,
> even if that code is hit only on ppc.  The value is host-endian - we've
> got it from readl(), after all...

> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
>  drivers/serial/8250.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)

> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> index 0ae9ced..10c2daa 100644
> --- a/drivers/serial/8250.c
> +++ b/drivers/serial/8250.c

    Shouldn't this go to rmk+serial@arm.linux.org.uk instead?

> @@ -320,8 +320,8 @@ #endif
>  
>  	case UPIO_TSI:
>  		if (offset == UART_IIR) {
> -			tmp = readl((u32 *)(up->port.membase + UART_RX));
> -			return (cpu_to_le32(tmp) >> 8) & 0xff;
> +			tmp = readl(up->port.membase + (UART_IIR & ~3));
> +			return (tmp >> 16) & 0xff; /* UART_IIR % 4 == 2 */
>  		} else
>  			return readb(up->port.membase + offset);
>  

    I'd also like to suggest actually writing to IER in the serial_out() even 
if the UUE bit is set, jusk mask 2 MSBs off (Xscale UART detection code which 
breaks Tsi10x UART sould have been CONFIG_ARM dependent I think). The whole 
UPIO_TSI thing looks much like an abuse to me, however it still seems to be a 
necessary evil... :-/

WBR, Sergei