On Fri, Aug 13, 2010 at 05:16:46PM -0700, Greg KH wrote:
> Ah, the infamous dtr/rts issue.
>
> Daniel, here's another user reporting that your fix checked in as commit
> id 6a1a82df91fa0eb1cc76069a9efe5714d087eccd, which showed up in
> 2.6.32.15, is causing problems again.
>
> Any ideas what to do about this?
Ok, we need to get this settled once for good. I copied some other
people who reported similar trouble. Let me try to summarize again what
I believe is the problem.
The USB protocol of this chip has two functions to modify the hardware
handshake lines. One is FTDI_SIO_SET_FLOW_CTRL_REQUEST and the other
is FTDI_SIO_SET_MODEM_CTRL_REQUEST. To fully enable or disable DTR/RTS
lines, appearantly both commands need to be sent to the chip. There are
two convenience macros for SET_MODEM_CTRL_REQUEST: {set,clear}_mctrl().
Up to 2.6.32-rc8, the chip wouldn't raise or lower DTR/RTS lines when
the device was opened and and the termios functions were used to set
the parameters. The only way to make this happen was to call ioctl on
the handle with TIOCMBI[CS], as this ends up in ftdi_dtr_rts() which
calls the functions {set,clear}_mctrl() properly according to the flags
passed. However, only calling the standard termios functions from
userspace didn't suffice as the DTR/RTS lines remained untouched by
ftdi_setermios(). SET_FLOW_CTRL_REQUEST was sent correctly though, but
obviously that's not enough. This alone looks like a bug to me.
Then Alan's patch 4175f3e31 ("tty_port: If we are opened non blocking we
still need to raise the carrier") came in in 2.6.32-rc8 which changed
the behaviour for all serial drivers by directly raising the DTR/RTS
lines upon each device open. For the ftdi_sio low-level driver, this
means that both SET_FLOW_CTRL_REQUEST and SET_MODEM_CTRL were called
which fully enabled hardware flow control. This isn't a problem per se,
as long as the standard userspace approaches to control the handshake
mode are properly implemented in the low-level driver, which they
weren't for ftdi_sio, as I pointed out above. So this change broke
support for all ftdi_sio users who happened to have hardware which has
no hardware flow control (like mine), unless an ioctl() with TIOCMBIC
was manually sent after the termios initialization.
What my patch (6a1a82df ("USB: ftdi_sio: fix DTR/RTS line modes")) does
is to properly raise/lower the lines according to the CRTSCTS flags in
set_termios(), which I believe is correct. However, I do see that this
might cause regressions for users who set their termios to a handshake
mode which doesn't reflect the actual hardware requirements. If the
hardware _does_ need proper DTR/RTS line handling but termios was made
believe it _doesn't_ (by not passing CRTSCTS), the device would still
have worked before my patch came in. Now, the driver does that is was
told to do.
Unfortunately, I see no good way to fix this and still keep all existing
users happy as they're simply dealing with with wrong settings and the
driver can't guess which mode the user actually needs. So people should
really fix their clients.
But - maybe I miss any essential information here. If that's the case,
please let me know.
Thanks,
Daniel
--
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
