A quick background for Greg and others who haven't seen the Sept-Oct discussion between me and Johan on the linux-usb ML: I am the hardware engineer who designed the FT2232D-based DUART28C adapter board, and it was my desire to have this custom FT2232D adapter supported in mainline Linux that triggered the chain of discussions and patch revisions that led to the present patch series by Johan. My FTDI-based USB to dual UART adapter is special in that the DTR & RTS signals on one of the two UART channels (FT2232D Channel B specifically) have been repurposed for a non-serial, non-modem-control use: they control open drain drivers (a Nexperia 74LVC2G07 buffer IC) which drive PWON & RESET control signals that would otherwise be driven by short-to-ground human-finger-operated pushbutton switches. The standard Unix/POSIX/Linux behaviour (going all the way back to 1970s Original UNIX) of automatically asserting DTR & RTS on serial port open is a killer for custom hw in which these signals have been repurposed, thus I need some way to suppress this automatic DTR & RTS assertion on tty device open. With automatic assertion on open suppressed, these two signals can then be freely manipulated by userspace via TIOCMBIS and TIOCMBIC. There have certainly been other serial devices in the past (whether true RS-232 or USB-serial) in which DTR and/or RTS has been repurposed for some non-standard use that does not tolerate unwanted auto-assert on every device open, and to the best of my knowledge this problem does not occur on Windows - thus it is quite possible that some other hw engineer somewhere out there could design and build a custom serial or USB-serial device with repurposed DTR/RTS that works fine under Windows, but the moment someone in Linux community tries to get it working under our free OS, they will run into the problem of unwanted DTR & RTS auto-assertion on device open. In our previous discussion Johan said "this has come up the in past", referring to repurposed DTR and/or RTS signals doing non-standard things, thus I find it a little surprising that this issue hasn't been solved long before my time - but I guess I must be the first to complain loudly enough to get something done about it, and someone always has to be the first... Johan's patch series provides two workable solutions to the problem of unwanted DTR & RTS auto-assertion: 1) For hardware engineers like me who design and build their own boards with the USB-serial chip fully embedded and who have their own custom USB IDs, a driver quirk can be applied (as part of adding support for the new USB ID) that sets the new tty port flag upon detecting the USB ID of the custom hw device for which it is required - this approach provides the highest level of friendliness to the ultimate end user of the finished hardware product. 2) For situations in which the luxury of a custom USB ID is not available, e.g., a situation where the device that does not tolerate automatic DTR/RTS assertion on open is a physical RS-232 device that can be connected to "any" serial port, the new sysfs attribute comes to the rescue. Johan's patch comments say that the new flag can also be brought out to termios in the future, similarly to HUPCL, but I question the usefulness of doing so, as it is a chicken and egg problem: one needs to open the tty device in order to do termios ioctls on it, and if that initial open triggers DTR/RTS hardware actions, then the end user is still screwed. If Johan or someone else can see a potential use case for manipulating this new flag via termios (as opposed to sysfs or USB-ID-based driver quirks), perhaps you could elaborate on it? Andy Shevchenko wrote: > > Add a nordy sysfs attribute to suppress raising the modem-control lines > > on open to signal DTE readiness. > > Why not call it nomctrl ? I have no opinion one way or another as to what the new sysfs attribute should be called - my use case won't involve this sysfs mechanism at all, instead I care much more about the path where the tty port flag gets set via a driver quirk upon seeing my custom USB ID. :) The naming of the internal tty port flag is likewise a matter which I gladly leave to more qualified kernel developers like Johan and Greg. In any case, it would be really awesome if this patch series (with or without further modifications) can make it into 5.10 - any chance of such happening, or will it have to be pushed out to 5.11? Sincerely, Mychaela, freelance hardware and software engineer, she/her/hers
