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

[Jeff Garzik <jeff@garzik.org>]

Andrew Morton wrote:
> Well I queued up a tentative revert patch but then I re-read the changlog:
> 
>     x86, serial: convert legacy COM ports to platform devices
>     
>     Make x86 COM ports into platform devices and don't probe for them
>     if we have PNP.
>     
>     This prevents double discovery, where a device was found both by
>     the legacy probe and by 8250_pnp, e.g.,
>     
>         serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>         00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

If this actually causes a problem, then the drivers are buggy.  We have 
standard APIs for checking this stuff...

Turning off legacy serial probing is just a bandaid, the resource bug is 
still there [by definition, if double-probing problems exist].


>     This also means IRDA devices without a UART PNP ID will no longer be
>     claimed by the serial driver, which might require changes in IRDA
>     drivers and administration.

This was completely unaddressed, I presume?


>     In addition to this patch, you may need to configure a setserial init
>     script, e.g., /etc/init.d/setserial, so it doesn't poke legacy UART
>     stuff back in.  On Debian, "dpkg-reconfigure setserial" with the "kernel"
>     option does this.

So this patch breaks some userspace too?


>     To force the old legacy probe behavior even when we have PNPBIOS or
>     ACPI, load the new legacy_serial module (or build 8250 static) with
>     the "legacy_serial.force" option.
> 
> So 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26 fixed a bunch of longstanding
> nasties while breaking Sebastien's machine (at least).
> 
> We of course want the best of both worlds here, so I'll keep the revert
> patch in -mm for a while, see what happens.  Although I can't immediately
> see any way in which this can be fixed...

I see VERY few positives, a whole lot of trouble, and a couple band-aids.

	Jeff