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.