On Thu, Dec 10, 2020 at 11:41:24AM +0100, Maarten Brock wrote: > Hello Mychaela, > > On 2020-12-09 23:49, Mychaela Falconia wrote: > > 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. Ehh, don't be silly. Relying on having Linux assert DTR/RTS on open is in no way a bug; it's the standard behaviour that we must continue to support unless explicitly overridden. Period. > > 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. Not every system use devicetree and no, it doesn't help with hotpluggable buses either. Johan
