Message-ID: <2025111227-equipment-magnetism-1443@gregkh>
Date: Wed, 12 Nov 2025 14:39:00 -0500
From: Greg KH <gregkh@...uxfoundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Theodore Ts'o <tytso@....edu>, Maarten Brock <Maarten.Brock@...ls.nl>,
	"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

Trimming out stuff to get to the real questions:

On Wed, Nov 12, 2025 at 11:12:22AM -0800, H. Peter Anvin wrote:
> Things that I have identified, at least in my opinion:
> 
> 1. Opening a device for configuration as opposed to data streaming; in the tty case that doesn't just improve the DTR# and RTS# issue but allows setserial, configuring line disciplines and so on.
> 
> As I have said, this is application-specific intent, which is why I strongly believe that it needs to be part of the open system call. I furthermore believe that it would have use cases beyond ttys and serial ports, which is why I'm proposing a new open flag as opposed to a sysfs attribute, which actually was my initial approach (yes, I have already prototyped some of this, and as referenced before there is an existing patchset that was never merged.)

I think this is going to be the most difficult.  I don't remember why I
rejected the old submission, but maybe it would have modified the
existing behaviour?  A new open flag "O_DO_NOT_TOUCH_ANYTHING" might be
the simplest?

> 2. Currently the setserial configurables are available in sysfs, but *only* for UARTs, whereas TIOC[GS]SERIAL is at least available to all serial devices. That code should presumably be hoisted into a higher layer; this shouldn't be too difficult.

I agree, this shouldn't be hard, no reason to not do this.

> 3. The only way to determine the type of a tty driver is reading and parsing /proc/tty/drivers; that information is exported neither through ioctl nor sysfs. Exporting *that* through sysfs is probably the easiest of all the improvements.

The "type" is interesting.  We keep adding new "types" of serial ports
to the uapi list, and they don't really show up very well to userspace,
as you say.  Adding this export to sysfs is fine with me, but we should
make it a string somehow, and not just a random number like the current
types are listed as, to give people a chance to keep track of this.

So yes, this too should be done.

> 4. There isn't a device-independent way to determine if a device is "real" (configured for hardware) or not without opening it and executing one of the termios ioctls like TCGETS (returns -EIO if there isn't anything behind it.) For a UART port it is possible to come up with an educated guess based on the aforementioned sysfs properties (does it have any kind of address associated with it?), but seriously, should stty -a /dev/ttyS0 really glitch RTS# and DTR# even though there is no intent of using the port for communication? 

Determining "realness" is going to be hard I think (is a usb-serial
device real or not?  Some are, some are not, but how do we even know?)
Does a "real" uart mean that the device is real?  How do you define
that?  What about virtual ones?  Modem chips that do have full line
discipline support on USB connections?  There's a lot out there to deal
with here and I think some "fake" ones do pass TCGETS calls just because
they lie.)

And addresses are only the "very old" method, many "real" PCI uarts
don't have them, same for USB ones.

And changing 'stty -a' is going to be hard, unless you want to use the
new flag?

But yes, making this more sane is always good, 2 of your things here
should be pretty simple to knock up if someone wants to.  The others
might be more difficult just due to backwards compatibility issues.

thanks,

greg k-h

Powered by blists - more mailing lists