From: Tom Rini <trini@kernel.crashing.org>
To: linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
Date: Wed, 24 Aug 2005 14:47:34 -0700 [thread overview]
Message-ID: <20050824214734.GE15735@smtp.west.cox.net> (raw)
In-Reply-To: <20050824213521.GA5397@siegfried.thelikelysolution.ca>
On Wed, Aug 24, 2005 at 03:35:21PM -0600, Grant Likely wrote:
> 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@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.
I'll buy that, and slightly modify this for 2.6.14, thanks.
> 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
The general problem here (Holy crap! arch/ppc/boot/common/ns16550.c uses
everything we'd like to kill from <asm*/serial.h>) is come up before,
and is being slowly fixed.
--
Tom Rini
http://gate.crashing.org/~trini/
next prev parent reply other threads:[~2005-08-24 21:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-23 22:47 [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE Grant Likely
2005-08-24 18:35 ` Tom Rini
2005-08-24 21:35 ` Grant Likely
2005-08-24 21:47 ` Tom Rini [this message]
2005-08-24 22:17 ` Grant Likely
-- strict thread matches above, loose matches on Subject: below --
2005-08-23 22:07 Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050824214734.GE15735@smtp.west.cox.net \
--to=trini@kernel.crashing.org \
--cc=linuxppc-embedded@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).