* Alexander Shishkin <[email protected]> [100105 08:56]: > Commit f62349ee9788b1d94c55eb6c291d74a1f69bdd9e makes it possible to > have some other than first uart port as ttyS0, which breaks the workaround > serial_in_override() function which will try to address the first uart > port (for ttyS0) and not the one that was initialized.
Nothing wrong with this patch.. But so we're back to having the ports move around again? That sucks. I wonder if we can initialize dummy 8250 ports somehow to keep the order correct to avoid confusion. Regards, Tony > Signed-off-by: Alexander Shishkin <[email protected]> > CC: Mika Westerberg <[email protected]> > CC: Kevin Hilman <[email protected]> > --- > arch/arm/mach-omap2/serial.c | 12 ++++++++++-- > 1 files changed, 10 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c > index 19805a7..8c964be 100644 > --- a/arch/arm/mach-omap2/serial.c > +++ b/arch/arm/mach-omap2/serial.c > @@ -125,6 +125,13 @@ static struct plat_serial8250_port > serial_platform_data3[] = { > } > }; > #endif > +static inline unsigned int __serial_read_reg(struct uart_port *up, > + int offset) > +{ > + offset <<= up->regshift; > + return (unsigned int)__raw_readb(up->membase + offset); > +} > + > static inline unsigned int serial_read_reg(struct plat_serial8250_port *up, > int offset) > { > @@ -583,11 +590,12 @@ static unsigned int serial_in_override(struct uart_port > *up, int offset) > { > if (UART_RX == offset) { > unsigned int lsr; > - lsr = serial_read_reg(omap_uart[up->line].p, UART_LSR); > + lsr = __serial_read_reg(up, UART_LSR); > if (!(lsr & UART_LSR_DR)) > return -EPERM; > } > - return serial_read_reg(omap_uart[up->line].p, offset); > + > + return __serial_read_reg(up, offset); > } > > void __init omap_serial_early_init(void) > -- > 1.6.3.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
