lkml.org 
[lkml]   [2020]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
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

\
 
 \ /
  Last update: 2020-12-10 13:09    [W:0.094 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site