On 2020-12-10 11:50, Greg Kroah-Hartman wrote:
On Thu, Dec 10, 2020 at 11:41:24AM +0100, Maarten Brock wrote:
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.
The "problem" of a vid:pid is that for usb-serial devices, that only
describes the device that does the conversion itself, NOT the serial
device the converter is plugged into that cares about these types of
line-wiggling.
Just like you would not want to classify all devices that met the PCI
serial class signature for this type of thing either, there is nothing
special about USB here other than it happens to be a common transport
for these signals these days.
thanks,
greg k-h
This is true for a generic USB-UART board or cable, but not for a
dedicated PCB where both the USB-UART chip and the special connection
are implemented and which has a dedicated VID:PID different from any
generic one. In this case the VID:PID describes the whole board.
If the line-wiggling requirement is created behind some sort of
connector (real RS-232 DB9/DB25 or CMOS pin header or whatever)
then the problem is the same as for an 8250 on any other bus. For
this situation I would prefer the O_DIRECT flag on open().
Maarten
