On Mon, Jul 29, 2002 at 10:43:41AM -0700, Tom Rini wrote:

On Mon, Jul 29, 2002 at 06:17:02PM +0100, Russell King wrote:

quoted

1. Serial port initialisation
-----------------------------

Firstly, one thing to bear in mind here is that, as Alan says "be nice
to make sure it was much earlier".  I guess Alan's right, so we can get
oopsen out of the the kernel relatively easily, even when we're using
framebuffer consoles.

I'm sure Alan will enlighten us with his specific reasons if required.

There have been several suggestions around on how to fix this table:

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.

I think this would be the cleanest method as well.  Especially when we
recognize that the asm-ppc/serial.h situation will only get worse
over time.  Every embedded PPC board designer has a unique location
for his 16550 UART(s) and we just keep adding more preprocessor
cruft for each port.  This should let us keep this board-specific
info in our board port files...more abstraction=good.

Regards,
-- 
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.