Re: RFC: Serial port DTR/RTS - O_NRESETDEV

[H. Peter Anvin]

On November 10, 2025 7:51:43 PM PST, Theodore Ts'o <tytso@xxxxxxx> wrote:
>On Mon, Nov 10, 2025 at 01:05:55PM -0800, H. Peter Anvin wrote:
>> 
>> 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.)
>
>I'm not an RS-485 expert, but over the years, I've heard all sorts of
>"interesting" timing requirements.  For example RTS can only be
>dropped when the UART's shift register has completely drained.  That's
>not when the OS has sent the characters to the FIFO (which is why
>tcdrain isn't quite what you want); it's not when the UART has sent
>the transmit interrupt, but when the UART's shift register is *empty*.
>Doing this via the termios interface is decidedly non-optimal[1].
>
>[1] https://www.moxa.com.cn/getmedia/a07808dd-f3d7-473b-9a2f-93b5ce673bb1/moxa-the-secrets-of-rs-485-half-duplex-communication-tech-note-v1.0.pdf
>
>It *can* be done, sure, with some strategic usleep()'s, but not
>necessarily optimally, and it is decidedly hacky.  From what I can
>tell, it's actually not *that* different from treating RTS as a GPIO
>pin, and really, this ought to be done in the kernel if you want
>optimal control oer the timing of when RTS gets toggeled.
>
>> *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).
>
>Well, part of the problem is that the PC's serial port predates PCI,
>so there's no way we can tell whether or not there is a serial port at
>a particular I/O port except by poking certain I/O ports, and seeing
>if there is something that looks like a UART which responds.
>Hopefully this won't accidentaly cause the NSA's thermite-charge
>self-destruct charge from getting set off, and in practice, mainboard
>designers who try to put things at the COM1/2/3/4 generally get weeded
>out thanks to natural selection, hopefully without harming users along
>the way.  :-)
>
>Worse, we also wanted to support serial cards that were at
>non-standard ports, or using non-standard interrupts, and so that's
>one of the reason hardware initialization is deferred until after we
>have a chance to configure the serial device's I/O port and interrupt.
>
>Now, we are in the 21st century, and just as we are trying to declare
>32-bit i386 dead (to the disappointment of legacy hardware owners
>everywhere who are whining about Debian dropping installer support for
>i386), we could try to declare the ISA bus as dead, and no longer
>being supported, and we could probably drop a bunch of this
>complexity.  We probably would need to support COM 1/2/3/4 ports since
>these still tend to be hardwared without a way of detecting it their
>existing via USB or PCI bus discovery mechanisms.  And for those, we
>would still need to do UART autoconfiguration.  I suppose we could
>just assume that all UART's are 16550A's, and that noone would
>actually use older UART's type --- except (a) I bet there are some
>cheap-skate embedded computer designers who decided to use a 8250
>instead of 16550A for $REASONS$, and because of the extreme timing
>requirements of some RS-485 use cases, I believe I have seen
>recommendations to use setserial to actually force the UART into 8250
>mode, to disable the TX FIFO --- all to satisfying the weird-shit RTS
>timing requirements.  (This is where I get my beief that RS-485 !=
>RS-232, and if you want to do all of this weird-shit timing
>requirements because you are trying to implemet a multi-node bus which
>is half-duplex, maybe this should be done in the kernel, damn it!)
>
>
>How about this?  If you really don't want to open the device to
>configure it not to assert DTR/RTS, perhaps we could specify on the
>boot command line that one of TTYS[0123] has a different default line
>discipline, and when tty's are opened when the RS-485 line displine,
>the RS-485 rules apply, which would include not messing with DTR/RTS,
>and if you want to play games with RTS getting dropped as soon as the
>last bit has let the transmit shift register, we can get the kernel do
>this in the line discpline, which arguably would be *way* more
>reliable than playing GPIO-style timing games in userspace.
>
>	      	      		 	      - Ted

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. 

Honestly, though, I'm far less interested in what 8250-based hardware does than e.g. USB.