On Wed, Mar 26, 2003 at 7:33 AM, Henrique Gobbi wrote:
>
> Thanks for the feedback.
>
> > If PARENB is set you generate parity. It is ODD parity if PARODD
> > is set, otherwise it's EVEN. There is no provision to generate
> > "stick parity" even though most UARTS will do that. When you
> > generate parity, you can also ignore parity on received data if
> > you want. This is the IGNPAR flag.
>
> Ok. But, considering the 2 states of the flag IGNPAR, what should the
> driver do with the chars that are receiveid with wrong
> parity, send this
> data to the TTY with the flag TTY_PARITY or just discard this data ?
>
Hi Henrique,
The driver should send all characters with parity errors to the line
discipline marked with TTY_PARITY. The driver is supposed to handle the
hardware. The line discipline is supposed to handle any higher level
protocol. Ideally, the driver should not know or care about the state of
flags like IGNPAR, that are not needed to configure the hardware.
Two common exceptions are:
1. "smart" UART hardware that directly handles some of the higher level
protocol, so the driver needs to know the higher level settings so it can
configure the hardware properly.
2. defensive actions to avoid bogging down the whole system with interrupt
storms from noisy or unconnected modem status inputs, where the driver could
mask off interrupts on modem status when the higher level options dictate
that all such status will be ignored.
Cheers,
Ed
----------------------------------------------------------------
Ed Vance edv (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:28 EST