mbox series

[0/5] tty: add flag to suppress ready signalling on open

Message ID 20201130153742.9163-1-johan@kernel.org (mailing list archive)
Headers show
Series tty: add flag to suppress ready signalling on open | expand

Message

Johan Hovold Nov. 30, 2020, 3:37 p.m. UTC
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(-)

Comments

Mychaela Falconia Nov. 30, 2020, 9:22 p.m. UTC | #1
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
Jiri Slaby Dec. 1, 2020, 7:14 a.m. UTC | #2
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,
Mychaela Falconia Dec. 1, 2020, 7:18 a.m. UTC | #3
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~
Johan Hovold Dec. 1, 2020, 8:40 a.m. UTC | #4
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
Andy Shevchenko Dec. 1, 2020, 10:48 a.m. UTC | #5
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.
Johan Hovold Dec. 1, 2020, 10:58 a.m. UTC | #6
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
Johan Hovold Dec. 2, 2020, 11:48 a.m. UTC | #7
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
Jiri Slaby Dec. 4, 2020, 6:58 a.m. UTC | #8
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,
Johan Hovold Dec. 8, 2020, 9:30 a.m. UTC | #9
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