| Message ID | 20201130153742.9163-1-johan@kernel.org |
|---|---|
| Headers | show |
| Series | tty: add flag to suppress ready signalling on open | expand |
On Mon, Nov 30, 2020 at 5:42 PM Johan Hovold <johan@kernel.org> wrote: > > Add a nordy sysfs attribute to suppress raising the modem-control lines > on open to signal DTE readiness. > > This can be use to prevent undesirable side-effects on open for > applications where the DTR and RTS lines are used for non-standard > purposes such as generating power-on and reset pulses. ... > + ret = kstrtouint(buf, 0, &val); > + if (ret) > + return ret; > + > + if (val > 1) > + return -EINVAL; kstrtobool() ?
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
On 30. 11. 20, 22:22, Mychaela Falconia wrote: > 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, The difference to other control flags is that open raises DTR/RTS in any case (i.e. including O_NONBLOCK) -- provided baud rate is set (and it is for casual serials). That means you cannot open a port to configure it (using e.g. setserial) without actually raising the DTR/RTS. > 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? We would need to (ab)use another open flag (e.g. O_DIRECT). I am not biased to either of solutions. thanks,
On 11/30/20, Jiri Slaby <jirislaby@kernel.org> wrote: > The difference to other control flags is that open raises DTR/RTS in any > case (i.e. including O_NONBLOCK) Yes, this is the exact root-cause problem I am trying to fix, with Johan's help. > -- provided baud rate is set (and it is > for casual serials). That means you cannot open a port to configure it > (using e.g. setserial) without actually raising the DTR/RTS. Exactly. M~
On Mon, Nov 30, 2020 at 01:22:07PM -0800, Mychaela Falconia wrote: > 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? Depending on the application it may be acceptable to assert the modem-control lines on first open (e.g. before initialisation). A new termios flag allows for a generic interface which could be shared with other OSes and controlled through stty. In case that isn't sufficient and you need control over the default port setting, you can always fall back to the Linux-specific sysfs interface. > 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? Let's see, but I don't think this necessarily has to take that long to get merged. Johan
On Tue, Dec 01, 2020 at 07:54:10AM +0100, Jiri Slaby wrote: > On 30. 11. 20, 16:37, Johan Hovold wrote: > > --- a/drivers/usb/serial/ftdi_sio.c > > +++ b/drivers/usb/serial/ftdi_sio.c > ... > > @@ -2386,6 +2393,21 @@ static int ftdi_stmclite_probe(struct usb_serial *serial) > > return 0; > > } > > > > +/* > > + * FreeCalypso DUART28C is an FT2232D-based USB to dual UART adapter > > + * with a special quirk: Channel B RTS and DTR outputs (BDBUS2 and BDBUS4 > > + * on the chip) have been repurposed to drive PWON and RESET controls. > > + */ > > +static void ftdi_duart28c_setup(struct usb_serial_port *port) > > +{ > > + struct usb_serial *serial = port->serial; > > + struct usb_interface *intf = serial->interface; > > + int ifnum = intf->cur_altsetting->desc.bInterfaceNumber; > > + > > + if (ifnum == 1) > > + tty_port_set_nordy(&port->port, 1); > > So s/1/true, provided the parameter is defined as bool now. Also here I'm following the convention used for the other port-flag helper which are used with numerical constants (just about) consistently throughout the tree. Johan
On Mon, Nov 30, 2020 at 11:25 PM Mychaela Falconia <mychaela.falconia@gmail.com> wrote: ... > 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? Thanks for the very detailed description of what you are working on. Unfortunately I have no thoughts about alternative solutions. > 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. :) Then why do we bother with sysfs right now? It's an ABI and Johan is completely aware and knows that once it's in the kernel it is close to being carved in stone. I would vote to remove sysfs from now and see if we really need it in the future.
On Tue, Dec 01, 2020 at 12:48:48PM +0200, Andy Shevchenko wrote: > On Mon, Nov 30, 2020 at 11:25 PM Mychaela Falconia > <mychaela.falconia@gmail.com> wrote: > > > 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. :) > > Then why do we bother with sysfs right now? It's an ABI and Johan is > completely aware and knows that once it's in the kernel it is close to > being carved in stone. > I would vote to remove sysfs from now and see if we really need it in > the future. Eh, because this is generally useful and has come up in the past. I'm not interested in adding quirks for odd devices that want non-standard behaviour that we need to maintain indefinitely; that's precisely why I proposed a general interface that can be use with any serial port. Johan
On Tue, Dec 01, 2020 at 08:14:07AM +0100, Jiri Slaby wrote: > On 30. 11. 20, 22:22, Mychaela Falconia wrote: > > 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, > > The difference to other control flags is that open raises DTR/RTS in any > case (i.e. including O_NONBLOCK) -- provided baud rate is set (and it is > for casual serials). That means you cannot open a port to configure it > (using e.g. setserial) without actually raising the DTR/RTS. Right, but depending on the application this may be ok (e.g. reset and initialise on first open after boot, which may have triggered a reset anyway). If control over first open is needed, the sysfs interface provides that out-of-band. > > 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? > > We would need to (ab)use another open flag (e.g. O_DIRECT). I am not > biased to either of solutions. Forgot to mention that using open-flags would prevent using standard utilities like cat, echo and terminal programs. So for that reason a termios and/or sysfs interface is also preferred. Johan
On 02. 12. 20, 12:48, Johan Hovold wrote: >>> 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? >> >> We would need to (ab)use another open flag (e.g. O_DIRECT). I am not >> biased to either of solutions. > > Forgot to mention that using open-flags would prevent using standard > utilities like cat, echo and terminal programs. So for that reason a > termios and/or sysfs interface is also preferred. Nope, I meant it differently. You set it up once using the special open flag. Like with setserial, one sets I/O port, irqs etc. and then uses standard tools as the port is already set up (marked as NORDY in this case). thanks, -- js
On Fri, Dec 04, 2020 at 07:58:53AM +0100, Jiri Slaby wrote: > On 02. 12. 20, 12:48, Johan Hovold wrote: > >>> 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? > >> > >> We would need to (ab)use another open flag (e.g. O_DIRECT). I am not > >> biased to either of solutions. > > > > Forgot to mention that using open-flags would prevent using standard > > utilities like cat, echo and terminal programs. So for that reason a > > termios and/or sysfs interface is also preferred. > > Nope, I meant it differently. You set it up once using the special open > flag. Like with setserial, one sets I/O port, irqs etc. and then uses > standard tools as the port is already set up (marked as NORDY in this > case). Ok, but leaving the open flag abuse aside, that would still require a custom tool to do the setup. There are also no other examples of such an interface with a "sticky" open flag affecting later opens. But you probably meant that the open flag only affects the current open, and then the termios flag is used to make the setting stick. Note that having a udev rule handle this at boot using a sysfs interface does not require any custom tools at all. And in theory nothing prevents extending/abusing POSIX with such an open behaviour later. Johan
This series adds a new NORDY port flag to suppress raising the modem-control lines on open to signal DTE readiness. This can be used to implement a NORDY termios control flag to complement HUPCL, which controls lowering of the modem-control lines on final close. Initially drivers can export the flag through sysfs, which also allows control over the lines on first open. Such an interface is implemented for serial core and USB serial. The motivation for this is to allow for applications where the DTR and RTS lines are used for non-standard purposes (e.g. generating power-on and reset pulses) to open the port without undesirable side effects. The final patches enables this flag by default for such a USB serial device. Greg, are you ok we me taking this through my tree? I'm planning on some follow ups to the ftdi driver and the tty/serial changes are fairly self-contained. Johan Johan Hovold (3): tty: add port flag to suppress ready signalling on open serial: core: add sysfs attribute to suppress ready signalling on open USB: serial: add sysfs attribute to suppress ready signalling on open Mychaela N. Falconia (2): USB: serial: ftdi_sio: pass port to quirk port_probe functions USB: serial: ftdi_sio: add support for FreeCalypso DUART28C adapter Documentation/ABI/testing/sysfs-tty | 7 +++++ drivers/tty/serial/serial_core.c | 29 ++++++++++++++++++++ drivers/tty/tty_port.c | 2 +- drivers/usb/serial/bus.c | 38 ++++++++++++++++++++++++-- drivers/usb/serial/ftdi_sio.c | 42 +++++++++++++++++++++++------ drivers/usb/serial/ftdi_sio_ids.h | 1 + include/linux/tty.h | 14 ++++++++++ 7 files changed, 122 insertions(+), 11 deletions(-)