On Wednesday 25 July 2007 01:45:54 am Sébastien Dugué wrote:
> looks like the commit was dropped, nevertheless here is some more info
> to try and understand what may be going on so it may benefit the posterity ;-)
Thank you very much.
Your machine does indeed describe both UARTs in ACPI, and the PNP probe
finds them correctly. The only wrinkle is that the PNP probe names the
ports in the order they appear in the ACPI namespace, and your firmware
has them "backwards":
Device (COMB)
{
Name (_HID, EisaId ("PNP0501"))
Name (_DDN, "COM2")
Name (_UID, 0x02)
Device (COMA)
{
Name (_HID, EisaId ("PNP0501"))
Name (_DDN, "COM1")
Name (_UID, 0x01)
There's nothing illegal about this, but with the current PNPACPI,
it causes the names to be reversed. The blind probe tries 0x3f8
first, and names that ttyS0. But the PNP probe, using the namespace
order, finds the "COM2" port at 0x2f8 first:
00:0b: ttyS0 at I/O 0x2f8 (irq = 3) is a 16550A
00:0c: ttyS1 at I/O 0x3f8 (irq = 4) is a 16550A
So I think your serial console would work without "legacy_serial.force"
if you used "console=ttyS1" instead of "console=ttyS0". But you
shouldn't have to do that, of course.
The _DDN is a "DOS device name", and the _UID is a "logical device ID
that does not change across reboots." Both are optional, and PNPACPI
ignores them. But maybe we could change PNPACPI to sort by them if
they are present. I'll think about this a bit.
Thanks again,
Bjorn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
