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
