> On Jun 28, 2017, at 11:17 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Wed, Jun 28, 2017 at 07:11:00AM +0200, Greg KH wrote: >> On Tue, Jun 27, 2017 at 06:32:07PM -0600, Philip Prindeville wrote: >>> What’s odd is that when I look in /dev/ I see ttyS0…S3, even though >>> there are only 2 hardware ports (a single DUART). >>> >>> [root@kvm2 logwatch]# setserial -G /dev/ttyS0 >>> /dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 115200 spd_normal skip_test >>> [root@kvm2 logwatch]# setserial -G /dev/ttyS1 >>> /dev/ttyS1 uart 16550A port 0x02f8 irq 3 baud_base 115200 spd_normal skip_test >>> [root@kvm2 logwatch]# setserial -G /dev/ttyS2 >>> /dev/ttyS2 uart unknown port 0x03e8 irq 4 baud_base 115200 spd_normal skip_test >>> [root@kvm2 logwatch]# setserial -G /dev/ttyS3 >>> /dev/ttyS3 uart unknown port 0x02e8 irq 3 baud_base 115200 spd_normal > > The "uart unknown port" for /dev/ttyS2 and /dev/ttyS3 means that the > driver knows that nothing is there. If you try reading or writing to > those devices you will get an EIO error. > >>> >>> [ 3.173481] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled >>> [ 3.194077] 00:03: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A >>> [ 3.214710] 00:04: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A > > Yep, working as designed. > >>> I was trying to figure out where this happens, and why, so maybe I >>> could submit a patch to allow one to suppress this behavior (say with >>> “8250.only_real_hw=1” or some other module parameter). > > The fact that you can set and get the settings of /dev/ttyS2 and > /dev/ttyS3 is a feature, not a bug. This is so if you have a system > with an old-style bus that doesn't allow you to enumerate what devices > are attached to which I/O ports, you can manually configure those > ports using the setserial command. Just out of curiosity, how many of those systems are still out there? > > It isn't necessary with modern buses (e.g., PCI or USB), for legacy > hardware (e.g., ISA buses) this is necessary. Aren’t most kernels built with CONFIG_ISA=n these days? > >>> Anyone know the backstory on why this happens, and how to >>> (conditionally) change this behavior? >> >> Why do you need to change this? What is wrong with the existing way >> this works? As for the code that implements it, it's the platform >> driver for your system that thinks the serial ports are there to remain >> compatible with the old PC standard. > > Philip, > > The current behaviour is not a bug, and should NOT be changed. The > legacy COM1..COM4 ports are not on an enumeratable bus (since they are > essentially emulated ISA bus devices). So the only way we can tell > whether or not they are there by probing to see if the UART is there. > That's why ttyS2 and ttyS3 exist inside the kernel. If you are > mortally offended that /dev/ttyS2 and /dev/ttyS3 as device nodes > exist, I suppose it could be possible to hack up some udev rules that > check to see if the UART is unknown, and then delete the device nodes, > but is it really worth the effort? > > - Ted Not mortally offended, no, or I wouldn’t still be alive. ;-) The reason is that I’m running a terminal server (ser2net) which has legacy ports on the motherboard and a PCI-e multi-UART card as well. I’d like to have all the (physical) ports be enumerated (and therefore named) consecutively. This would allow me to map the ttySn number to 2001+n as the port to connect to, and having a single consecutive block means having a single hole in my firewall rules for 2002-(2001+n) -- they can’t connect to ttyS0 as that’s the console. In my case, the kernel *is* probing for and finding the correct hardware type for ttyS0 and ttyS1... and properly identifying the absence of ttyS2 and ttyS3. A new module parameter could trivially say “don’t create ports we can’t identify properly”. This could default to false so that legacy behavior is preserved. -Philip -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
