[PATCH 4/6] bootwrapper: Add non-OF serial console support

[Mark A. Greer]

On Wed, Aug 02, 2006 at 09:17:12AM -0700, Tom Rini wrote:
> On Wed, Jul 19, 2006 at 04:12:44PM -0700, Mark A. Greer wrote:
> 
> > This patch adds support for serial I/O to the bootwrapper.
> > 
> > It is broken into 2 layers.  The first layer is generic serial
> > operations that calls uart-specific routines to do the actual I/O.
> > The second layer contains support for a 16550 compatible uart.
> > 
> > The division allows support for other serial devices to be easily
> > added in the future (e.g., the Marvell MPSC and the Freescale CPM).
> 
> Why do we do this with indirection rather than weak defaults and then
> real implementations?

Remember, devtrees can be added years after the zImage built.
So what if you had a board with 4 serial ports, 2 MPSC, 2 16550/8250
and the /chosen/linux,stdout-path could choose any of the four?

The current code doesn't handle that now either :) but it easily
could (and I should make it handle that).  The reason for the
indirections and not weak routines is to allow maximum flexibility.

Once things become more concrete, we can look at what can be replaced
by weak routines.  Now isn't the time, IMHO.

> The only places I see that are data are:
> 
> > +	ns16550_scd.base = NULL;
> > +	ns16550_scd.reg_shift = 0;
> 
> And I imagine that on platforms where these are real, we dig them out of
> the tree and set them, in your scheme, so it'd just be an empty (return
> 0/NULL) weak function, or the dig in the tree function.  Heck, it could
> just always be a 'dig in the tree' function.

I'm sorry, but I can't parse this paragraph.

What I probably should do, is rework serial_open() to query the dt
to get the stdout-path, match it up to one of the low-level serial
drivers that's been linked into the zImage, hook it up, and can call
its open routine.  Its open routine can then look for the properies
it needs in the devtree.  Something like that.

Again, when things have settled down, we can convert indirects to weak
routines where it makes sense.  But also remember, that the zImage
doesn't necessarily know a priori what's going to be in its devtree
(unless what's been compiled & linked into the zImage is so minimal
that it allows it no options--maybe that ends up always being the case,
I don't know).

Mark