Message-ID: <0F8021E8-F288-4669-8195-9948844E36FD@zytor.com>
Date: Mon, 10 Nov 2025 13:05:55 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: "Theodore Ts'o" <tytso@....edu>, Maarten Brock <Maarten.Brock@...ls.nl>
CC: "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Serial port DTR/RTS - O_NRESETDEV

On November 10, 2025 12:19:33 PM PST, Theodore Ts'o <tytso@....edu> wrote:
>On Mon, Nov 10, 2025 at 10:06:02AM +0000, Maarten Brock wrote:
>> I fully agree that you cannot expect users that wired something like RS485 Driver
>> Enable or a microcontroller reset to RTS or DTR to write their own kernel driver.
>> And you need to open the port to make the appropriate settings. But opening a
>> port should not e.g. claim the RS485 bus and mess up whatever communication
>> was going on there.
>
>Again, the existing seral driver code *will* mess with RTS and DTR at
>boot up because that's part of the autoconfiuration code, and that was
>added because it was needed for some number of serial ports.
>
>If that's going to "mess up" the RS485 bus, maybe we need accept that
>RS-232 != RS-485 and have a different driver for the two.  That's
>going to be a lot simpler than trying to make the same code work for
>both RS-232 and RS-485, and claiming that the existing RS-232 code is
>"fundamentally buggy" when it interacts poorly with something that has
>very different requirements than the historical RS-232 use cases.
>
>              	  	     	    - Ted

I didn't say it was fundamentally buggy; if I did or implied it I apologize. It is most definitely not; however, in some cases it is undesired or undesirable *due to shifts in usage patterns.*

This isn't a bug at all but an enormous strength. That a 65-year-old standard — both hardware and software — designed for teletypes and dumb terminals can still be useful today is almost the definition of success. And, yes, some glitches in that process are going to be inevitable — like the mistake of retaining the termio Bxxx emumeration constants in the termios interface. But we deal with it by gradual evolution of interfaces. 

One such example is RTS itself: the RS485 definition is, in fact, the originally intended meaning of RTS: it is a request to the DCE to negotiate transmission privilege and activate transmission mode over a half duplex channel, after which it asserts CTS. RTS/CTS flow control was a nonstandard adaption to allow for binary transparent flow control over full duplex links — it wasn't formally standardized until 1991, and the signal is formally named RTR when used that way. However, RTR and RTS share hardware in nearly all existing implementations, and share pins in the standard — so whether or not you are using RTR or RTS is a property of the DCE, not DTE, and needs to be configured into the DTE.

Requiring new drivers for the gajillion different hardware devices already supported and then having the problem of which drivers claim it isn't really any better of a solution; one could in fact argue it is *exactly* equivalent to being able to indicate to the driver what mode one wants it to operate in before it does its configuration.

The parport driver layer is kind of similar to this, in some ways, but in the tty layer that is mostly handled by line disciplines instead. (The parport hardware was generally abused on a much lower level, as a substitute for GPIOs, so even the notion of a byte stream wasn't there.)

*If* I'm reading the code correctly – which is a little complicated due to the sheer number of abstraction layers – hardware initialization is already deferred until first open, which would mean that disabling autoconfiguration (one of the features in TIOCSSERIAL) would again be a valid reason for wanting to be able to communicate with a device driver before requiring that it puts the underlying hardware in the state expected for operation *in the mode configured* (catch-22).

As I stated, this is inherently going to be a best effort. For some devices that may mean simply leaving the power on default in place (in this specific case, presumably, DTR# and RTS# deasserted.) However, once the state is already known to the kernel then there is no such issue for any hardware. 

As far as naming is concerned: O_RAW is really suboptimal, as it has exactly the same implications as O_DIRECT (I/O goes straight to the device with no buffering.) I don't like the idea of abusing O_DIRECT at all; I only brought it up as a fallback alternative. I genuinely do believe that if we assign a new open flag it will find use cases outside the tty/serial port subsystems, and if there is anything Unix has done right it is to generalize interfaces as much as possible, case in point descriptors. 

Powered by blists - more mailing lists