On Sun, Sep 12, 2010 at 06:56:03PM +0100, Alan Cox wrote:
> This seems unwise to revert
>
> Either behaviour has people complaining about things not working. One of
> them is the behaviour which provide generally, the other is port non
> standard.
>
> Surely we should favour the standard behaviour given we have to pick one ?
I agree fully, but my point is that reverting the patch is what would
give us the standard behaviour. That is, RTS/DTR are asserted on port
open and _not_ cleared if the user calls set_termios without CRTSCTS.
This is what ftdi_sio has been doing since as far back as git history
goes (i.e. way before 4175f3e31:"tty_port: If we are opened non
blocking we still need to raise the carrier" which was supposed to have
introduced the regression that the patch in question was supposed to fix).
Daniel's patch instead introduced a new non-standard behaviour in that
1. RTS/DTR is first raised at port open (by tty layer)
2. RTS/DTR is then lowered at set_termios with standard settings
(called from driver open).
3. RTS/DTR is then raised again if user sets CRTSCTS.
The old behaviour would not toggle the lines at open in this way (we
would not lower the lines in 2).
And it's perfectly consistent to raise RTS/DTR if not using flow control
which even the original authors of ftdi_sio made explicit:
"/* Turn on RTS and DTR since we are not flow controlling by
default */"
This is also the behaviour of serial_core which asserts RTS/DTR on open
and does not lower after them if CRTSCTS is not set.
Perhaps I am missing something, but to me it seems that Daniel's patch is
taking us farther away from the standard behaviour.
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
