svn commit: r239414 - stable/9/sys/kern

[Ian Lepore]

On Mon, 2012-08-20 at 12:07 +0000, Konstantin Belousov wrote:
> Author: kib
> Date: Mon Aug 20 12:07:10 2012
> New Revision: 239414
> URL: http://svn.freebsd.org/changeset/base/239414
> 
> Log:
>   MFC r232197 (on behalf of phk):
>   Also call the low-level driver if ->c_iflag & (IXON|IXOFF|IXANY) changes.
>   
>   Uftdi(4) examines (c_iflag & (IXON|IXOFF)) to control hw XON-XOFF support.
>   This is obviously no good, if changes to those bits are not communicated
>   down the stack.
> 
> Modified:
>   stable/9/sys/kern/tty.c
> Directory Properties:
>   stable/9/sys/   (props changed)
> 
> Modified: stable/9/sys/kern/tty.c
> ==============================================================================
> --- stable/9/sys/kern/tty.c	Mon Aug 20 11:51:49 2012	(r239413)
> +++ stable/9/sys/kern/tty.c	Mon Aug 20 12:07:10 2012	(r239414)
> @@ -1498,6 +1498,8 @@ tty_generic_ioctl(struct tty *tp, u_long
>  		 */
>  		if ((t->c_cflag & CIGNORE) == 0 &&
>  		    (tp->t_termios.c_cflag != t->c_cflag ||
> +		    ((tp->t_termios.c_iflag ^ t->c_iflag) &
> +		    (IXON|IXOFF|IXANY)) ||
>  		    tp->t_termios.c_ispeed != t->c_ispeed ||
>  		    tp->t_termios.c_ospeed != t->c_ospeed)) {
>  			error = ttydevsw_param(tp, t);

I think this is the wrong fix for this problem.  The correct fix is to
get the uftdi driver and hardware out of the business of managing
software flow control, because it cannot do so properly.  For example,
the hardware has no support for the concept of IXANY.  Also, this change
is insufficient for communicating changes of the VSTART and VSTOP chars
to the hardware.  

When I was working on the uftdi driver recently I saw situations where
the hardware and software (tty layer) got out of sync on the state of
flow control when the driver/hardware were doing the XON/XOFF handling,
locking up comms until the device was closed and reopened (and that may
have un-wedged things primarily because the ftdi driver inappropriately
does a reset of the hardware on open(2)).

I have a large set of fixes and enhancements to the uftdi driver, I've
just had too many irons in the fire recently to get them packaged up and
submitted for review.  I guess maybe it's time to get that done.

-- Ian