Re: [RFC][PATCH] Way for platforms to alter built-in serial ports
From: Bjorn Helgaas (bjorn.helgaas_at_hp.com)
Date: 10/01/04
- Previous message: Denis Vlasenko: "Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone."
- In reply to: Benjamin Herrenschmidt: "Re: [RFC][PATCH] Way for platforms to alter built-in serial ports"
- Next in thread: Benjamin Herrenschmidt: "Re: [RFC][PATCH] Way for platforms to alter built-in serial ports"
- Reply: Benjamin Herrenschmidt: "Re: [RFC][PATCH] Way for platforms to alter built-in serial ports"
- Reply: Russell King: "Re: [RFC][PATCH] Way for platforms to alter built-in serial ports"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: Fri, 1 Oct 2004 08:58:27 -0600
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Denis Vlasenko: "Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone."
- In reply to: Benjamin Herrenschmidt: "Re: [RFC][PATCH] Way for platforms to alter built-in serial ports"
- Next in thread: Benjamin Herrenschmidt: "Re: [RFC][PATCH] Way for platforms to alter built-in serial ports"
- Reply: Benjamin Herrenschmidt: "Re: [RFC][PATCH] Way for platforms to alter built-in serial ports"
- Reply: Russell King: "Re: [RFC][PATCH] Way for platforms to alter built-in serial ports"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
