RE: Interpretation of termios flags on a serial driver

RE: Interpretation of termios flags on a serial driver

[Ed Vance]

On Wed, Mar 26, 2003 at 4:17 PM, Henrique Gobbi wrote:
> 
> Hello Ed !
> Thanks for the feedback. 
> 
> Please read my coments (doubts actually) below:
> 
> > > 4 - INPCK flag: What's the purpose of this flag. What's the 
> > > diference in 
> > > relation to IGNPAR;
> >      If INPCK is set, input parity checking  is  enabled.      If
> >      INPCK is  not  set, input parity checking is disabled.  This
> >      allows output parity generation without input parity errors.
> >      Note  that  whether input parity checking is enabled or dis-
> >      abled is independent of whether parity detection is  enabled
> >      or disabled. If parity detection is enabled but input parity
> >      checking is disabled, the hardware to which the terminal  is
> >      connected  will  recognize  the parity bit, but the terminal
> >      special file will not check whether this is set correctly or
> >      not.
> > 
> >      If IGNPAR is set, a  byte  with  framing  or  parity  errors
> >      (other than break) is ignored. This means that the data byte
> >      with the error is thrown away  by the  driver as if the byte
> >      had never been received. 
> > 
> > In short,
> > If INPCK is _not_ set, then all received data bytes will be 
> delivered 
> > to the user level, regardless of parity errors.
> > If IGNPAR is set, then only received data bytes that do not have 
> > parity errors will be delivered to the user level.
> > If PARENB is _not_ set, then the receiver hardware will not detect 
> > bad parity, so all received data bytes are considered free 
> of errors. 
> > Since there are no data bytes with associated error indications, 
> > setting IGNPAR would have no effect. All of the data are considered 
> > error free.
> 
> Your explanation makes sense to me. With this information I built the
> table:
>    IGNPAR    INPCK         ACTION:
>      0         0           Deliver all data to the user-level
>      0         1           Check parity. Discard erroneous bytes
>      1         0           ????
>      1         1           Check parity. Discard erroneous bytes 
> 
> What goes on ????   ?

   IGNPAR    INPCK         ACTION:
     0         0           Deliver all data to the user-level, as is.
     0         1           Deliver nulls in place of erroneous bytes
     1         0           Discard erroneous bytes, deliver the rest
     1         1           Discard erroneous bytes, deliver the rest 

IGNPAR gets processed before INPCK: 
(from drivers/char/n_tty.c:488)

static inline void n_tty_receive_parity_error(struct tty_struct *tty,
                                              unsigned char c)
{
        if (I_IGNPAR(tty)) {
                return;          /* discard data */
        }
        if (I_PARMRK(tty)) {
                put_tty_queue('\377', tty);
                put_tty_queue('\0', tty);
                put_tty_queue(c, tty);
        } else  if (I_INPCK(tty))
                put_tty_queue('\0', tty);     /* deliver null */
        else
                put_tty_queue(c, tty);        /* deliver data */
        wake_up_interruptible(&tty->read_wait);
}

> 
> > > 5 - If the TTY knows the data status (PARITY, FRAMING, 
> > > OVERRUN, NORMAL), 
> > > why the driver has to deal with the flag IGNPAR. Shouldn't 
> > > the TTY being 
> > > doing it ?
> > 
> > Not sure I understand the question. Received data does not carry any
> > information about errors with it after it leaves the driver, unless 
> > PARMRK is set. 
> 
> When the driver copy the data from the controler to the flip buffer it
> copies the data to the buffer tty->flip.char_buf_ptr and it set a flag
> (TTY_NORMAL, TTY_PARITY, TTY_FRAME, etc) on the buffer
> tty->flip.flag_buf_ptr telling the TTY how this byte was received. So
> the TTY knows if certain byte was problematic or not. Did you 
> understand my doubt know ?

Yes. I call that part a "line discipline". n_tty is the TTY line 
discipline that implements termio(s) and some legacy functionality.

And yes, for received data with parity errors, the line discipline 
handles IGNPAR, as well INPCK and PARMRK. See snippet of n_tty.c above. 

> 
> Thanks for your patience
> Henrique
> 

Cheers,
Ed

---------------------------------------------------------------- 
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

Re: Interpretation of termios flags on a serial driver

[David Lawyer]

On Wed, Mar 26, 2003 at 04:59:11PM -0800, Ed Vance wrote:
> On Wed, Mar 26, 2003 at 4:17 PM, Henrique Gobbi wrote:
> > 
> > Hello Ed !
> > Thanks for the feedback. 
> > 
> > Please read my comments (doubts actually) below:
> > 
> > > > 4 - INPCK flag: What's the purpose of this flag. What's the 
> > > > difference in relation to IGNPAR;
[snip]
> > 

>From the code snippet, it seems that INPCK only determines how to "mark"
a parity error (when PARENB is set and IGNPAR is unset) and can be
overridden by PARMRK (prefixes the bad char. with \377\0).  INPCK has
no effect unless IGNPAR and PARMRK are both unset.  If they are both
unset then: INPCK set results in the bad character being replaced by \0,
while if INPCK is unset, then the bad character (less the parity bit) is
passed thru.  I've use "mark" in a broad sense, since in one case it's
not marked at all and in the other case it's marked by deleting it and
substituting a \0.

The man page for termios needs revision to make this clear.  One can't
just say that INPCK "enables parity checking"; it's a lot more involved.

> 
>    IGNPAR    INPCK         ACTION:
>      0         0           Deliver all data to the user-level, as is.
>      0         1           Deliver nulls in place of erroneous bytes
>      1         0           Discard erroneous bytes, deliver the rest
>      1         1           Discard erroneous bytes, deliver the rest 
> 
> IGNPAR gets processed before INPCK: 
> (from drivers/char/n_tty.c:488)
> 
> static inline void n_tty_receive_parity_error(struct tty_struct *tty,
>                                               unsigned char c)
> {
>         if (I_IGNPAR(tty)) {
>                 return;          /* discard data */
>         }
>         if (I_PARMRK(tty)) {
>                 put_tty_queue('\377', tty);
>                 put_tty_queue('\0', tty);
>                 put_tty_queue(c, tty);
>         } else  if (I_INPCK(tty))
>                 put_tty_queue('\0', tty);     /* deliver null */
>         else
>                 put_tty_queue(c, tty);        /* deliver data */
>         wake_up_interruptible(&tty->read_wait);
> }
> 
> > 
> > > > 5 - If the TTY knows the data status (PARITY, FRAMING, 
> > > > OVERRUN, NORMAL), 
> > > > why the driver has to deal with the flag IGNPAR. Shouldn't 
> > > > the TTY being 
> > > > doing it ?
> > > 
> > > Not sure I understand the question. Received data does not carry any
> > > information about errors with it after it leaves the driver, unless 
> > > PARMRK is set. 
> > 
> > When the driver copy the data from the controller to the flip buffer it
> > copies the data to the buffer tty->flip.char_buf_ptr and it set a flag
> > (TTY_NORMAL, TTY_PARITY, TTY_FRAME, etc) on the buffer
> > tty->flip.flag_buf_ptr telling the TTY how this byte was received. So
> > the TTY knows if certain byte was problematic or not. Did you 
> > understand my doubt know ?
> 
> Yes. I call that part a "line discipline". n_tty is the TTY line 
> discipline that implements termio(s) and some legacy functionality.
> 
> And yes, for received data with parity errors, the line discipline 
> handles IGNPAR, as well INPCK and PARMRK. See snippet of n_tty.c above. 
> 
> > 
> > Thanks for your patience
> > Henrique
> > 
> 
> 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-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
			David Lawyer

RE: Interpretation of termios flags on a serial driver

[Ed Vance]

On Wed, Mar 26, 2003 at 6:51 AM, Henrique Gobbi wrote:
> 
> I'm having some problems understanding three flags on the termios 
> struct: PARENB, INPCK, IGNPAR. After reading the termios 
> manual a couple 
> of times I'm still not able to understand the different purposes of 
> these flags.
> 
> What I understood:
> 
> 1 - PARENB: if this flag is set the serial chip must generate parity 
> (odd or even depending on the flag PARODD). If this flag is 
> not set, use 
> parity none.
> 
> 2 - IGNPAR: two cases here:
>     	2.1 - PARENB is set: if IGNPAR is set the driver should 
> ignore 			all 
> parity and framing errors and send the problematic bytes to 	
> 	tty flip 
> buffer as normal data. If this flag is not set the 		
> 	driver must send the 
> problematic data to the tty as problematic 		data.
> 
> 	2.2 - PARENB is not set: disregard IGNPAR
> 
> What I don't understand:
> 
> 3 - Did I really understand the items 1 and 2 ?
> 
> 4 - INPCK flag: What's the purpose of this flag. What's the 
> diference in 
> relation to IGNPAR;

     If INPCK is set, input parity checking  is  enabled.      If
     INPCK is  not  set, input parity checking is disabled.  This
     allows output parity generation without input parity errors.
     Note  that  whether input parity checking is enabled or dis-
     abled is independent of whether parity detection is  enabled
     or disabled. If parity detection is enabled but input parity
     checking is disabled, the hardware to which the terminal  is
     connected  will  recognize  the parity bit, but the terminal
     special file will not check whether this is set correctly or
     not.

     If IGNPAR is set, a  byte  with  framing  or  parity  errors
     (other than break) is ignored. This means that the data byte
     with the error is thrown away  by the  driver as if the byte
     had never been received. 

In short,
If INPCK is _not_ set, then all received data bytes will be delivered 
to the user level, regardless of parity errors.
If IGNPAR is set, then only received data bytes that do not have 
parity errors will be delivered to the user level.
If PARENB is _not_ set, then the receiver hardware will not detect 
bad parity, so all received data bytes are considered free of errors. 
Since there are no data bytes with associated error indications, 
setting IGNPAR would have no effect. All of the data are considered 
error free.

> 
> 5 - If the TTY knows the data status (PARITY, FRAMING, 
> OVERRUN, NORMAL), 
> why the driver has to deal with the flag IGNPAR. Shouldn't 
> the TTY being 
> doing it ?

Not sure I understand the question. Received data does not carry any
information about errors with it after it leaves the driver, unless 
PARMRK is set. 
> 
> Thanks in advance
> Henrique

Cheers,
Ed

---------------------------------------------------------------- 
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

RE: Interpretation of termios flags on a serial driver

[Henrique Gobbi]

Hello Ed !
Thanks for the feedback. 

Please read my coments (doubts actually) below:

> > 4 - INPCK flag: What's the purpose of this flag. What's the 
> > diference in 
> > relation to IGNPAR;
>      If INPCK is set, input parity checking  is  enabled.      If
>      INPCK is  not  set, input parity checking is disabled.  This
>      allows output parity generation without input parity errors.
>      Note  that  whether input parity checking is enabled or dis-
>      abled is independent of whether parity detection is  enabled
>      or disabled. If parity detection is enabled but input parity
>      checking is disabled, the hardware to which the terminal  is
>      connected  will  recognize  the parity bit, but the terminal
>      special file will not check whether this is set correctly or
>      not.
> 
>      If IGNPAR is set, a  byte  with  framing  or  parity  errors
>      (other than break) is ignored. This means that the data byte
>      with the error is thrown away  by the  driver as if the byte
>      had never been received. 
> 
> In short,
> If INPCK is _not_ set, then all received data bytes will be delivered 
> to the user level, regardless of parity errors.
> If IGNPAR is set, then only received data bytes that do not have 
> parity errors will be delivered to the user level.
> If PARENB is _not_ set, then the receiver hardware will not detect 
> bad parity, so all received data bytes are considered free of errors. 
> Since there are no data bytes with associated error indications, 
> setting IGNPAR would have no effect. All of the data are considered 
> error free.

Your explanation makes sense to me. With this information I built the
table:
   IGNPAR    INPCK         ACTION:
     0         0           Deliver all data to the user-level
     0         1           Check parity. Discard erroneous bytes
     1         0           ????
     1         1           Check parity. Discard erroneous bytes 

What goes on ????   ?

> > 5 - If the TTY knows the data status (PARITY, FRAMING, 
> > OVERRUN, NORMAL), 
> > why the driver has to deal with the flag IGNPAR. Shouldn't 
> > the TTY being 
> > doing it ?
> 
> Not sure I understand the question. Received data does not carry any
> information about errors with it after it leaves the driver, unless 
> PARMRK is set. 

When the driver copy the data from the controler to the flip buffer it
copies the data to the buffer tty->flip.char_buf_ptr and it set a flag
(TTY_NORMAL, TTY_PARITY, TTY_FRAME, etc) on the buffer
tty->flip.flag_buf_ptr telling the TTY how this byte was received. So
the TTY knows if certain byte was problematic or not. Did you understand
my doubt know ?

Thanks for your patience
Henrique