psarc/2009/197 - UFTDI - fast-track

[Tim Marsland]

James Carlson wrote:
> Tim Marsland writes:
>> This case asserts that, moving forward, the default behaviour
>> for "off-board" serial ports should be the same as "on-board"
>> serial ports -- the distinction being particularly ambiguous
>> in the case of USB simulations of RS232 devices.
> 
> I can understand why this is the default for possibly broken hardware
> (devices ordinarily lacking standard modem control lines), and when we
> discussed the issue, I had thought that was the context for the
> change.
> 
> However, I don't think it makes sense as a general rule for all
> off-board serial ports.  The only reason it's the default for on-board
> ports is because of the common (and legacy) usage of /dev/term/a as a
> console port with a three-wire connection to an ASCII terminal.  In
> fact, given the legacy nature, I'd be much more in favor of saying
> that going forward all ports -- both on-board and off-board -- should
> *NOT* have the "ignore-cd" property set by default.
> 
> I'd settle for saying that ignore-cd=1 is the default for UFTDI,
> because of an unusual risk of broken hardware in this particular usage
> case (as I thought we'd discussed), but I don't think it's right as a
> general rule.  It provides for strange operation at best, and security
> problems (such as disconnected lines being left logged in) at worst.
> 
> (The better answer is for the driver to supply the default: if the
> hardware is known to be deficient or otherwise "special," then using
> ignore-cd=1 as the default is fine.  If it's known to be a properly
> functioning serial port with a reasonble complement of modem control
> lines, then it should be ignore-cd=0.)

I was really trying to capture the class of USB serial devices that
are mostly *not* used in the role of modems.   Which increasingly
seems to be all of them, as modems become an increasingly arcane
concept except for debugging and low-level hardware hacking.

However, if you want to restrict that statement to the
usbftdi driver, I'm fine with that too.

tim