Hello Mychaela,
On 2020-12-09 23:49, Mychaela Falconia wrote:
Greg K-H wrote:
I think we need more review for the rest of the series. This does
change the way serial ports work in a non-traditional way (i.e. using
sysfs instead of terminal settings).
But the problem is that the current status quo is fundamentally broken
for those hardware devices in which DTR and/or RTS have been repurposed
for something other than modem and flow control. Right now whenever a
"cold" (never previously opened) serial port is opened for the first
time, that open action immediately and unstoppably asserts both DTR
and RTS hardware outputs, without giving userspace any opportunity to
say "no, please don't do it". Yes, this behaviour is codified in a
bunch of standards that ultimately trace back to 1970s Original UNIX,
but just because it is a standard does not make it right - this
Unix/POSIX/Linux "standard" serial port behaviour is a bug, not a
feature.
I agree. And an application not configuring the required handshakes, but
still relying on them is an equal bug.
But if there exist some custom hw devices out there that are in the
same predicament as my DUART28 adapter, but are different in that they
are classic old-fashioned RS-232 rather than integrated USB-serial,
with no place to assign a custom USB ID, *then* we need a non-USB-ID-
dependent solution such as Johan's sysfs attribute or O_DIRECT.
Any device with a classic old-fashioned RS-232 has probably already
solved this in another way or is accepted as not working on Linux.
And then there is also the device tree (overlay?) through which a quirk
like this can be communicated to the kernel driver. Not sure if this
could help for a plug-and-play device like on USB.
So I want to get a bunch of people
to agree that this is ok to do things this way now before taking this
new user-visible api.
Personally, I would prefer the VID:PID to enforce the quirk and an
O_DIRECT (or other) flag used on open() as general backup plan. To
me a sysfs solution seems illogical.
If the concern is with the new sysfs interface or the proposed O_DIRECT
alternative, how about deferring those while allowing specific USB ID
support to go in first? Right now there already exists at least one
piece of hardware actively supported by its manufacturer (my gadget)
that has a custom USB ID and requires the quirk - what is wrong with
adding support for this existing specific hw? How about merging
Johan's patch that defines the NORDY flag in tty_port, merging the
ftdi_sio driver patch setting this flag for my custom USB ID, allowing
other hardware engineers in the same boat to submit similar quirk
patches for their affected custom hw with custom USB IDs, while
deferring the sysfs patches until there is a more pressing need for
quirky devices that have no custom USB IDs?
Sincerely,
Mychaela
Again, I agree.
Maarten
