On Thu, Jun 29, 2017 at 10:03:33PM -0600, Philip Prindeville wrote:
> > 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?
Actually, every single x86 system with a COM1, COM2, COM3, and/or COM4
port qualifies. That's because COM1..COM4 are effectively as if they
are on the ISA, in that they aren't enumerated on the PCI bus or some
other modern bus. They just *appear* on specific port addresses,
i.e., 0x3F8 for COM1, 0x2F8 for COM2, 0x3E8 for COM3, 0x2E8 for COM4.
And they have specific irq's that are also hard-coded: irq 4 for COM1
and COM3, and irq 3 for COM2 and COM4. Things on the PCI bus, such as
a graphics or WIFI peripheral, have IRQ's come out of a very different
number space:
% cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 27 0 0 0 IR-IO-APIC 2-edge timer
1: 5178 554 4984 567 IR-IO-APIC 1-edge i8042
8: 0 0 1 0 IR-IO-APIC 8-edge rtc0
...
126: 8491 1270809 845085 13836 IR-PCI-MSI 32768-edge i915
127: 1148 45635 19126 6204 IR-PCI-MSI 2097152-edge iwlwifi
> Aren’t most kernels built with CONFIG_ISA=n these days?
Even machines that don't have an ISA bus, still have built-in "legacy"
devices that are provided by the chipset that are detected and
communicated with as if they were on the legacy ISA bus. If you want
to use these legacy ports, you probe them using the legacy rules, ISA
bus or no ISA bus.
> >>> 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.
And I've just said what Greg K-H has said much more succintly. (But
hopefully in a way that makes more sense to you.)
> 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”.
No, it's not trivial, because we have to create the port in order to
identify whether or not the UART is present. Basically, what the
driver is doing is saying, "create a port and call it ttyS2 since
that's next after ttyS1; assign to that port the hard-coded the I/O
port and irq to the legacy values for COM3; trigger the UART
autodetection code; and set the UART type accordingly".
The identification comes *after* the port creation. Is there a way
around this? Sure, maybe you might be able to use some ACPI method to
enumerate what legacy ports exist, and use that instead of the
hard-coded table in arch/x86/include/asm/serial.h. But it would be a
lot of work; there is no guarantee the ACPI method is present or works
corrently on all motherboards; and debugging it when users complain
about serial ports failing to be detected would be a b*tch.
Basically, it's **so** not worth it.
- Ted
--
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
