Re: commit 7e92b4fc34 - x86, serial: convert legacy COM ports to platform devices - broke my serial console

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

On Wednesday 25 July 2007 08:21:06 pm Shaohua Li wrote:
> On Wed, 2007-07-25 at 17:37 -0700, Yinghai Lu wrote:
> > On 7/25/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> > > On Wednesday 25 July 2007 07:32:53 am Sébastien Dugué wrote:
> > > > On Wed, 25 Jul 2007 07:16:44 -0600 Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> > > >
> > > > > 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.
> > >
> > > Yeah, it's an ugly world we live in.  Would you be able to try the
> > > attached patch just for testing?  It should sort devices with the
> > > same _HID by their _UID.  It doesn't have any effect on my systems,
> > > because my devices are already ordered by _UID by default.  But I
> > > think it should switch your COM1/COM2 ports back to the order you
> > > expect.
> > >
> > > Yinghai, you mentioned the same issue on boxes with multiple root
> > > bridges.  Any chance you could try this out there as well?
> > >
> > it doesn't solve pci_root_bus reverse problem.
> > 
> > is that too late for PNP0A03?
> > 
> > I wonder if we need to modify acpi_device_register to sort them.
> The pci root driver is an acpi driver not a pnp driver, so Bjorn's patch
> will not work. Maybe the ACPI core (ACPICA) should do the sort?

I talked to Adam about this yesterday.  He convinced me that we
shouldn't rely on device ordering to determine names.  For one
thing, that would make threaded probing difficult.  Better to
rely on a unique identifier, and let udev take care of user-space
persistent naming issues.

I don't think udev solves the problem for built-in drivers like
serial, where you need to be able to do "console=ttyS0" and have
it mean something predictable.  But possibly we could expose the
_DDN and/or _UID through PNP and have 8250_pnp give a hint about
what the ttyS device should be when it registers with 8250.

For example, 8250_pnp could have rules like "COM1 should always
be ttyS0" or "a port at 0x3f8 should always be ttyS0."

That doesn't help with Yinghai's PCI root ordering issue, of course.
But I hope that can be addressed with udev, because there's not so
much need for a persistent kernel name.  If that's not enough, can
you explain more about the problem?

Bjorn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/