On Tue, May 16, 2006 at 11:48:00AM +0200, Peter Korsgaard wrote: > >>>>> "Russell" == Russell King <rmk@xxxxxxxxxxxxxxxx> writes: > > Hi, > > Sorry for the slow reply, I've been away all weekend... > > >> Comments and suggestions are welcome. I'm especially wondering about > >> the fact that I'm hijacking the device nodes used by the mpc52xx_uart > >> driver .. > > Russell> That's for the mpc52xx folk to comment about. I personally > Russel> don't like> it. > > What do you say Sylvain? Reusing device nodes seems pretty common > (pxa.c, at91_serial.c, ..), and I cannot imagine anyone making a > system with uartlite and mpc52xx UARTs .. Actually they're wishing they hadn't because they can't interoperate with standard 16550-based ports without resorting to nasty hacks. As such they're _both_ transitioning away from using the major 4 space. > Talking about driver, the following seems wrong (or atleast doesn't > match 8250.c) > > The interaction of the iflag bits is as follows (parity error > given as an example): > Parity error INPCK IGNPAR > None n/a n/a character received > Yes n/a 0 character discarded > Yes 0 1 character received, marked as > TTY_NORMAL > Yes 1 1 character received, marked as > TTY_PARITY Actually that's wrong. INPCK controls whether input parity _checking_ is be enabled. If INPCK is not set, then there is no checking of input parity, and therefore you don't know if there is an error or not. IOW, INPCK takes precidence over IGNPAR. So, this should be: INPCK Parity error IGNPAR Action 0 n/a n/a character received, marked TTY_NORMAL 1 0 n/a character received, marked TTY_NORMAL 1 1 0 character received, marked TTY_PARITY 1 1 1 character ignored which I believe is what 8250 and other ports implement. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
