Re: [RFC][PATCH] Way for platforms to alter built-in serial ports

[Bjorn Helgaas]

On Thursday 30 September 2004 5:53 pm, Benjamin Herrenschmidt wrote:
> On Fri, 2004-10-01 at 02:14, Bjorn Helgaas wrote:
> 
> > This looks like a reasonable short-term fix, but I think the whole
> > serial8250_isa_init_ports() should go away.  I like dwmw2's suggestion
> > of an 8250_platform.c that could use register_serial() for each port
> > in some platform-supplied old_serial_port[] table, which is probably
> > what you mean by moving to a more dynamic allocation.
> 
> What would this file look like ? a bunch of platform #ifdef's with
> different implementations each time ? 

My main point is that I think the early init stuff (i.e.,
serial8250_isa_init_ports()) should go away, so we don't have the
dichotomy of having the compiled-in stuff handled differently than
the run-time enumerated stuff.

It really doesn't matter for ia64, since we discover all the ports
via either PCI enumeration or ACPI.  We don't put anything in
old_serial_port[] at all.  For platforms that can't do that,
there'd still have to be compiled-in tables, but the entries
should be added using the standard register_serial() interface
just like everything else.

> > AFAICS, the only reason for doing serial8250_isa_init_ports() early
> > is for early serial consoles, and I think those should be done along
> > the lines of this:
> >  http://www.ussg.iu.edu/hypermail/linux/kernel/0409.1/1034.html
> > where the platform can specify a device by its MMIO or IO port address,
> > and we automatically switch to the corresponding ttyS device later.
> 
> Eventually...
> 
> In the meantime, that patch would fix urgent problems for ppc now so
> I'd appreciate if Russell would consider it for inclusion asap. This
> is the kind of subject on which everybody comes up with a different
> "better" way to do it and no code, and nothign ever gets implemented
> and we end up with no progress...

We've both posted working code that are at least baby steps toward
a better solution, so I hope we can make some progress.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/