Hi Bjorn,

On Wed, 25 Jul 2007 07:16:44 -0600 Bjorn Helgaas <[EMAIL PROTECTED]> wrote:

> 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)


  Yes, that's what I thought was weird in the DSDT, but thought the PnP layer
would map those devices according to UID or at least DDN. It seems that's
not the case.

> 
> 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

  Oh I see, didn't notice this though.

> 
> 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.

  Will try ttyS1 just to confirm...

  Waiting for reboot...

  OK boots fine with the serial console fully operational again.

> 
> 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.

  That would be nice, but I wish you good luck with all those
crappy BIOSes out there.

  Thanks,

  Sébastien.


-
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/

Reply via email to