[Top] [All Lists]

Re: [patch] Incorrect mapping of serial ports to lines

To: Ralf Baechle <>
Subject: Re: [patch] Incorrect mapping of serial ports to lines
From: Jun Sun <>
Date: Tue, 29 Jun 2004 17:15:37 -0700
Cc: "Maciej W. Rozycki" <>, Geert Uytterhoeven <>, Linux/MIPS Development <>,
In-reply-to: <>; from on Wed, Jun 30, 2004 at 12:49:32AM +0200
Original-recipient: rfc822;
References: <> <> <> <> <> <> <>
User-agent: Mutt/1.2.5i
On Wed, Jun 30, 2004 at 12:49:32AM +0200, Ralf Baechle wrote:
> On Tue, Jun 29, 2004 at 03:13:13PM -0700, Jun Sun wrote:
> > > > The NEC DDB Vrc-5074 (and probably the other DDB variants as well) has 
> > > > one
> > > > serial port in the Nile 4 host bridge, and 2 serial ports in the Super 
> > > > I/O.
> > > > 
> > > > To me it sounds the most logical if the one in the Nile 4 is ttyS0.
> > > 
> > >  Then we need to find a way to make the order configurable somehow.
> > 
> > This is why I favor run-time serial port configuration.  My view
> > (maybe a little dramatic) is to remove all static serial port definition
> > and push them into board setup routine.  asm/serial.h only needs
> > to define the number serial lines, which itself could be configurable.
> <asm/serial.h> is on it's way out of the kernel - it's only a question of
> time until either the current maintainer of the serial driver or somebody
> with more time at hands will eleminate it.  And serial.h was always only
> meant to handle the kind of serial interfaces of which you just have to
> know that they're there because probing for it isn't possible.  Something
> which these days is getting increasingly more rare thanks to PCI.
> What I really wouldn't like to see is the runtime registration for all
> the legacy serial stuff that possibly could be plugged into some board
> be duplicated into half a dozen of systems ...

No fear really.  You can still provide STD_SERIAL_PORT in the asm/serial.h
where each individual board simply does a registration for each line
defined there.  You might even provide some inline function for 
doing so in asm/serial.h.

The big advantage of this scheme is that the board-level complexity is not 
exposed to MIPS arch layer.  So when it is time for a board to die, one
does not have to clean up a dozen or so common files like asm/serial.h file.

Of course it also offers complete control over the ordering of serial
ports to the board.

See arch/mips/vr4181/common/serial.c for a simple example of run-time
registeration.  I believe a couple of other boards are doing this too.


<Prev in Thread] Current Thread [Next in Thread>