[2/6] serial: core: add sysfs attribute to suppress raising DTR & RTS on open

Add a manual_rtsdtr sysfs attribute to suppress automatic raising of
DTR and RTS modem control signals on serial port open.

This special mode can be used to prevent undesirable side effects on
open for applications where these lines are used for non-standard
purposes such as generating power-on and reset pulses.

Co-developed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Mychaela N. Falconia <falcon@freecalypso.org>
---
 Documentation/ABI/testing/sysfs-tty | 10 ++++++++++
 drivers/tty/serial/serial_core.c    | 27 +++++++++++++++++++++++++++
 2 files changed, 37 insertions(+)

On Sat, May 28, 2022 at 2:22 AM Mychaela N. Falconia
<falcon@freecalypso.org> wrote:
>
> Add a manual_rtsdtr sysfs attribute to suppress automatic raising of
> DTR and RTS modem control signals on serial port open.
>
> This special mode can be used to prevent undesirable side effects on
> open for applications where these lines are used for non-standard
> purposes such as generating power-on and reset pulses.

As I read this I think of the pins used as GPIOs. So, sounds like what
we need instead is to list the pins that are used for (dedicated)
GPIOs and pass this information to serial mctrl layer and perhaps
prepare that layer to handle exclusions like these. The given (in this
series) approach sounds to me like a (hackish?) workaround of this
simple idea.

Andy Shevchenko wrote:

> As I read this I think of the pins used as GPIOs.

Viewing my repurposed DTR & RTS outputs as GPIOs is a valid way to
look at them.  The target application has one 8-wire UART, a secondary
2-wire UART, and two GPIO (really GPO, output-only) controls.  Because
no major USB-to-X chip vendor makes a chip that goes from one USB to
this combination of two UARTs plus GPIO (there are some that may seem
to qualify at first glance, such as CP2105, but that one and others I
know of have other issues that preclude their use), I took the next
most practical route: I used FT2232D, and repurposed its otherwise
unused Channel B DTR & RTS outputs to be GPOs.

> So, sounds like what
> we need instead is to list the pins that are used for (dedicated)
> GPIOs and pass this information to serial mctrl layer and perhaps
> prepare that layer to handle exclusions like these.

What you are describing would be quite easy to implement for *my*
device, and the implementation would be entirely contained in the
ftdi_sio driver.  My particular FTDI chip (FT2232D) doesn't have any
pins that are officially regarded as GPIOs, but other FTDI chips do
(single-channel FT232H, FT232R and FT-X), and Linux ftdi_sio driver
already has support for presenting FT232H/R/FT-X CBUS pins to gpiolib
as a gpio_chip.  It would be fairly easy to implement a second kind of
gpio_chip within ftdi_sio, made out of an otherwise-serial channel's
DTR and RTS outputs - but here is the big BUT: I don't know how to
conditionalize enabling of this special mode (stealing DTR & RTS from
the ttyUSBx device and handing them over to gpiolib control instead)
other than by keying on specific USB VID:PID codes.  The latter
approach would work great for my application, but I keep being told
that the solution must work for "everyone", whatever that global
specifier could mean in this context.

However, this idea of moving an FTDI device's DTR & RTS outputs to
gpiolib control at the ftdi_sio driver level will not help anyone who
has an old-fashioned RS-232 (not USB-serial) device in which DTR
and/or RTS have been repurposed in a way that does not tolerate
automatic unconditional assertion of these signals on open.  I don't
know whether or not any such devices exist: there aren't any in _my_
world, but I keep being told to think generically, outside of my own
repertoire of use cases.

At this point I need to ask the maintainers with decision-making
powers: which approach would be more acceptable?  The two approaches
which I see as feasible are:

Option 1: implement a special mode for all serial ports, both "hard"
and USB-serial, that suppresses automatic assertion of DTR & RTS on
open - but allows them to be controlled with TIOCMBIS and TIOCMBIC.
Yes, the signals are really GPIOs in this case, but just how would one
go about turning UART signals into true Linux GPIOs on any arbitrary
serial port, whenever an end user decides to connect a particular
RS-232 device that needs special handling?

Option 2: implement a VID:PID-keyed solution in the ftdi_sio driver,
stealing DTR & RTS completely from the tty device and handing them
over to gpiolib control.  This solution would work for my specific USB
device, and if anyone else builds anything similar, they could reuse
the same ftdi_sio driver quirk - but this solution provides no help at
all to RS-232 tinkerers, if any exist.

M~