All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mark A. Greer" <mgreer@mvista.com>
To: Kumar Gala <kumar.gala@freescale.com>
Cc: linuxppc-embedded@ozlabs.org, Kumar Gala <galak@somerset.sps.mot.com>
Subject: Re: RFC: [PATCH] platform device driver model support
Date: Thu, 13 Jan 2005 10:34:35 -0700	[thread overview]
Message-ID: <41E6B12B.1020705@mvista.com> (raw)
In-Reply-To: <579DFDF6-651A-11D9-92A0-000393DBC2E8@freescale.com>

Kumar Gala wrote:

>> My $0.02.
>>
>> I didn't go thru in complete detail but I like the idea.  I have a
>> couple minor comments, though.
>>
>> 1) Can we pick something other than 'soc' since the Marvell bridges
>>  really aren't SOCs?  I don't really know what is better but just to
>> throw something out, how about haing them all look like ppc_pd_xxx()?
>
>
> What about ppc_plat_xxx() or ppc_sys_xxx() [for system]?  'sys' maybe 
> more consistent with our naming conventions in that arch/ppc/platforms 
> is more board focused, and arch/ppc/syslib is bridge and non-core chip 
> functionality. 


ppc_sys_xxx() sounds good to me.

>
>
>> 2) In 8540_ads.c you're digging out platform_device entries and
>> modifying them in your mpc8540ads_setup_arch() routine.  I think the
>> platform_device "way" of doing that would be to make your mods via the
>> platform_notify() hook (eventually called by device_add() which was
>> ultimately called from platform_add_devices()).
>
>
> This is problematic for some things like the updating of the IOMEM 
> resources since that needs to occur before platform_device_register is 
> called.


I don't think so.  In fact, the platform_notify() will be called from 
[platform_add_devices()]/platform_device_register()/device_register()/device_add()/platform_notify().  
There is an example in the bk://source.mvista.com/linux-2.5-marvell tree 
inside arch/ppc/platforms/katana.c.  It was only a suggestion anyway, so 
its not a big deal.

Mark

      reply	other threads:[~2005-01-13 17:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-12  7:43 RFC: [PATCH] platform device driver model support Kumar Gala
2005-01-12  8:36 ` Eugene Surovegin
2005-01-12 14:41   ` Kumar Gala
2005-01-12 21:14   ` Matt Porter
2005-01-12 21:28     ` Matt Porter
2005-01-14 19:13     ` Andrew May
2005-01-14 19:14       ` Kumar Gala
2005-01-12 23:30 ` Mark A. Greer
2005-01-13  4:19   ` Kumar Gala
2005-01-13 17:34     ` Mark A. Greer [this message]

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=41E6B12B.1020705@mvista.com \
    --to=mgreer@mvista.com \
    --cc=galak@somerset.sps.mot.com \
    --cc=kumar.gala@freescale.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.