On Wed, Mar 26, 2003 at 03:33:26PM +0000, 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 ?
We follow POSIX, which says that if IGNPAR is set, bytes with framing
or parity errors (but not break's) are ignored. If IGNPAR is clear
and INPCK is set, check parity, and flag it via the TTY_PARITY flag.
If INPCK is clear, don't check parity at all.
Note that PARENB enables/disables the generation and reception of
parity. INPCK controls whether you detect received character parity
errors, and IGNPAR tells you what to do when a character with incorrect
parity is received.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
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:26 EST