From: Vitaly Bordug <vbordug@ru.mvista.com>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH 5/6] CPM_UART: unify clock sources
Date: Sat, 24 Jun 2006 19:21:36 +0400 [thread overview]
Message-ID: <20060624192136.41e9987d@localhost.localdomain> (raw)
In-Reply-To: <10C0FB27-7351-4578-9CE5-3EFA476C2661@kernel.crashing.org>
Kumar,
Thanks for feedback! My comment below.
On Sat, 24 Jun 2006 08:46:54 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
[snip]
> > +
> > +#ifndef FS_PD_H
> > +#define FS_PD_H
> > +
> > +#define GET_BAUDRATE() (((bd_t *) __res)->bi_baudrate ?
> > ((bd_t *) __res)->bi_baudrate : -1)
> > +#define FS_UART_CLK() (((bd_t *) __res)->bi_intfreq)
> > +
> > +#endif
>
> We shouldn't hide these differences in a header like this. As we
> slowly try to removing things from arch/ppc. Why not just add
> platform data for these two pieces of data and set it up like we do
> other platform data.
>
That was my first guess as well, but:
The aim is yet moving to powerpc not to break existing ppc/ stuff.
So if alternatively platform_data may be utilized, all relevant ppc
stuff that uses cpm uart should be updated. While doing the driver
"platformize" trick, I made it possible to keep legacy behaviour
(pd-less), this is not going to afford such a thing.
IOW, I don't see much sense in updating ppc/ BSP files, just to keep
the right way. It does not look very neat now, but does the job of
moving FW and keeping existing stuff sane. If there is better approach
envisioned, I'll definitely follow..
--
Sincerely, Vitaly
next prev parent reply other threads:[~2006-06-24 15:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060623231648.6721.3495.stgit@localhost.localdomain>
2006-06-23 23:16 ` [PATCH 1/6] PAL: Support of the fixed PHY Vitaly Bordug
2006-06-23 23:16 ` [PATCH 2/6] FS_ENET: Utilize Phy abstraction Vitaly Bordug
2006-06-23 23:17 ` [PATCH 3/6] FS_ENET: use PAL for mii management (BSP part) Vitaly Bordug
2006-06-23 23:17 ` [PATCH 4/6] FS_ENET: phydev pointer may be dereferenced without NULL check Vitaly Bordug
2006-06-23 23:17 ` [PATCH 5/6] CPM_UART: unify clock sources Vitaly Bordug
2006-06-24 13:46 ` Kumar Gala
2006-06-24 15:21 ` Vitaly Bordug [this message]
2006-06-24 15:50 ` Kumar Gala
2006-06-24 16:22 ` Jon Loeliger
2006-06-24 16:27 ` Kumar Gala
2006-06-23 23:17 ` [PATCH 6/6] [RFC] POWERPC: Add mpc8560 board support Vitaly Bordug
2006-06-24 16:26 ` Kumar Gala
2006-06-24 17:17 ` Vitaly Bordug
2006-06-26 13:35 ` Kumar Gala
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=20060624192136.41e9987d@localhost.localdomain \
--to=vbordug@ru.mvista.com \
--cc=galak@kernel.crashing.org \
--cc=linuxppc-dev@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).