3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Benjamin Herrenschmidt]

>> a. architectures provide a sub-module to 8250.c which contains the
>>    per-port details, rather than a table in serial.h.  This would
>>    ideally mean removing serial.h completely.  The relevant object
>>    would be linked into 8250.c when 8250.c is built as a module.
>
>I think this would work best.  On PPC this would allow us to change the
>mess of include/asm-ppc/serial.h into a slightly cleaner Makefile
>(especially if we do the automagic <platforms/platform.h> or
><asm/platform.h> bit that's been talked about in the past) magic and we
>could use that object file as well in the bootwrapper as well.

Especially, please, let's avoid once for all statically defined table,
on PPC (specifically on pmac) the table is really dynamic, and
the "legacy ports" (if any) may not be ttyS0..1, but could well be
2..3, or higher, all this having to be decided at runtime for both
built-in driver and modular (so eraly_serial_setup isn't good).

I quite like the sub-module mecanism. I'd rather have it done the
opposite though. I don't care that much about sharing those files
with the bootloader, and i'd rather see the core serial code beeing
a submodule of the arch specific module.

Typically, that would give us:

 - 8250_legacy.c would load 8250 core, probe legacy ports and
instanciate them for typical x86 setup
 - 8250_ppc.c would instanciate known ports on PReP or CHRP machines
and do nothing on pmac
 - 8250_pci.c would be a pci_driver and instanciate ports for a given
PCI card
 - 8250_cs.c would be a pcmcia driver and instanciate ports for a
given PCMCIA modem card

etc... And of course, we can have an arbitrary set of the above loaded
instanciating ports are they are found.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/