linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Kumar Gala <galak@kernel.crashing.org>
To: Vitaly Bordug <vbordug@ru.mvista.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH 5/6] CPM_UART: unify clock sources
Date: Sat, 24 Jun 2006 10:50:10 -0500	[thread overview]
Message-ID: <64AF3E64-2E2E-492F-9A8E-31268219BA8C@kernel.crashing.org> (raw)
In-Reply-To: <20060624192136.41e9987d@localhost.localdomain>


On Jun 24, 2006, at 10:21 AM, Vitaly Bordug wrote:

> 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..

Fair enough, then I would suggest getting ride of all this header/ 
MACRO indirection and just implement these as functions with  
different implementations in arch/powerpc vs arch/ppc.

- k

  reply	other threads:[~2006-06-24 15:50 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
2006-06-24 15:50       ` Kumar Gala [this message]
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=64AF3E64-2E2E-492F-9A8E-31268219BA8C@kernel.crashing.org \
    --to=galak@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=vbordug@ru.mvista.com \
    /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).