[PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE

[Grant Likely]

On Wed, Aug 24, 2005 at 11:35:20AM -0700, Tom Rini wrote:
> On Tue, Aug 23, 2005 at 04:47:02PM -0600, Grant Likely wrote:
> 
> > [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
> > 
> > REPOST: fixed formating problems in original patch
> > 
> > Modifies serial_init to get base baud rate from the rs_table entry instead
> > of BAUD_BASE.  Will default back to BAUD_BASE if base_baud is not set.
> > 
> > This patch eliminates duplication between the SERIAL_PORT_DFNS macro and
> > BAUD_BASE.  Without the patch, if a port set the baud rate in
> > SERIAL_PORT_DFNS, but did not update BASE_BAUD, the BASE_BAUD value
> > would still be used.
> > 
> > Rather; serial_init() should look first in SERIAL_PORT_DFNS and use
> > BASE_BAUD as a backup.
> > 
> > Signed-off-by: Grant Likely <grant.likely at gdcanada.com>
> 
> With everything in-tree, this is fine as baud_base is always set to
> BASE_BAUD, but I'm wondering why this was done.  Did you do a port and
> not follow on this?  It looks like today you could get away without
> defining BASE_BAUD correctly (8250_early uses and needs this to be
> correct, but I don't think this is frequently used, yet).  But I'm not
> sure what we gain here.  Thanks.
I stumbled across this while working on moving v2pro to the platform
bus.  (I'm also trying to isolate xparameter.h as much as possible to
avoid recompiling the world everytime I get a new bitstream).  I've got
the base baud for each port in the rs_table.

IMHO it doesn't seem right to have part of the serial parameters pulled
from rs_table and the base baud pulled from elseware.  ie. it looked
like a latent bug to me, so I wrote the patch.  I've also got the
impression that the serial subsystem is trying to move away from
depending on BASE_BAUD

Cheers,
g.