RE: RFC: Serial port DTR/RTS - O_NRESETDEV

[Maarten Brock]

Ted,

I don't understand why you drag userspace into this discussion.
The kernel drivers already support RS-485 mode for many/most
UARTs including the best timing they can give.

The reason I brought up RS-485 is because of the following situation:
Out of reset the UART has RTS# inactive. Any decent hardware design
will turn this into RS-485 Driver Enable (DE) inactive with the result that
it does not inadvertently claim the bus unnecessarily.

Now some userspace program wants to open the tty to start listening
and maybe later also to start transmitting. Opening the tty will activate
the RTS# line and thus DE and thereby claiming the bus. Any ongoing
communication will get disrupted. How's that for good behaviour?
Only after opening the port the userspace program can use the file
descriptor to configure the tty to use RS-485 mode and since it is not
transmitting it will now deactivate RTS# and DE again. But the possible
damage has been done.

Luckily if one is using a device tree one can already tell some drivers
that they need RS-485 mode and the glitch can be prevented.

But a flag to open a tty without touching the RTS# and DTR# lines would
bring the option of configuring the driver in RS-485 mode in a safe way.

And another reason why you should not handle this in a new driver is that
there are many RS-232 <-> RS-485 converters. Do you really expect users
to compile and install a new kernel just because they plugged in or out
some such converter?

Maarten

> -----Original Message-----
> From: Theodore Ts'o <tytso@xxxxxxx>
> Sent: Tuesday, 11 November 2025 05:38
> To: H. Peter Anvin <hpa@xxxxxxxxx>
> Cc: Maarten Brock <Maarten.Brock@xxxxxxxx>; linux-serial@xxxxxxxxxxxxxxx; linux-
> api@xxxxxxxxxxxxxxx; LKML <linux-kernel@xxxxxxxxxxxxxxx>
> Subject: Re: RFC: Serial port DTR/RTS - O_NRESETDEV
> 
> On Mon, Nov 10, 2025 at 07:57:22PM -0800, H. Peter Anvin wrote:
> > I really think you are looking at this from a very odd point of
> > view, and you seem to be very inconsistent. Boot time setup? Isn't
> > that what setserial is for? We have the ability to feed this
> > configuration already, but you need a file descriptor.
> 
> I'm not really fond of adding some new open flag that to me seems
> **very** serial / RS-485 specific, and so I'm trying to find some
> way to avoid it.
> 
> I also think that that the GPIO style timing requirements of RTS
> **really** should be done as a line discpline, and not in userspace.
> 
> > Honestly, though, I'm far less interested in what 8250-based hardware does than
> e.g. USB.
> 
> I'm quite confident that USB won't have "state" that will be preserved
> across a reboot, because the device won't even get powered up until
> the USB device is attached.  And part of the problem was that the
> requirements weren't particularly clear, and given the insistence that
> the "state" be preserved even across reboot, despite the serial port
> autoconfiguration, I had assumed you were posting uing the COM 1/2/3/4
> ports where autoconfiguration isn't stricty speaking necessary.
> 
> In some ways, USB ports might be easier, since it should be possible
> to specify udev rules which get passed to the driver when the USB
> serial device is inserted, and so *that* can easily be done without
> needing a file descriptor.
> 
> And for this sort of thing, it seems perfectly fair to hard code some
> specific behavior using either a boot command line or a udev rule,
> since you seem to be positing that the serial port will be dedicated
> to some kind of weird-shit RS-485 bus device, where any time RTS/DTR
> gets raised, the bus will malfunction in weird and wondrous ways....
> 
>      	     	     	  	      	 - Ted