linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Li Yang <LeoLi@freescale.com>
Cc: Wood Scott-B07421 <scottwood@freescale.com>,
	linuxppc-dev@ozlabs.org, devicetree-discuss@ozlabs.org
Subject: Re: The usage of compatible 'simple-bus'
Date: Wed, 7 Jan 2009 13:00:06 +1100	[thread overview]
Message-ID: <20090107020006.GD13731@yookeroo.seuss> (raw)
In-Reply-To: <3A45394FD742FA419B760BB8D398F9ED0B38C9@zch01exm26.fsl.freescale.net>

On Tue, Jan 06, 2009 at 01:46:21PM +0800, Li Yang wrote:
> > -----Original Message-----
> > From: 
> > devicetree-discuss-bounces+leoli=freescale.com@ozlabs.org 
> > [mailto:devicetree-discuss-bounces+leoli=freescale.com@ozlabs.
> > org] On Behalf Of David Gibson
> > Sent: Tuesday, January 06, 2009 9:43 AM
> > To: Wood Scott-B07421
> > Cc: linuxppc-dev@ozlabs.org; Li Yang-R58472; 
> > devicetree-discuss@ozlabs.org
> > Subject: Re: The usage of compatible 'simple-bus'
> > 
> > On Mon, Jan 05, 2009 at 01:20:53PM -0600, Scott Wood wrote:
> > > On Mon, Jan 05, 2009 at 06:27:39PM +0800, Li Yang wrote:
> > > > I got an assumption from the existing device trees that having 
> > > > 'simple-bus' in the compatible property of a node means that all 
> > > > child nodes should be added as of_platform_device in platform 
> > > > initialization phase.  No matter it represents a bus in 
> > common sense 
> > > > or not.  Is this truly the case?
> > > 
> > > Yes, simple-bus indicates that the children can be driven 
> > standalone 
> > > from any knowledge of the parent bus.
> > 
> > Erm, well, sort of.  Strictly it indicates that the only way 
> > to locate the child devices of this bus is by using the 
> > address information in the device tree - there's no way to 
> > dynamically probe the bus.
> 
> So if I understand correctly, "simple-bus" is intended to be used for
> true buses.

Generally, yes, although there may be some situations where it's
appropriate for other things.  So, for example, in some cases it's
used (correctly) for compound devices .  I don't think this particular
case is a sensible situation for it, though.

> > The fact that this causes of_platform_devices to be 
> > instantiated is a Linux implementation specific detail (and 
> > one we might change in future).
> 
> Here we have a common case for SoC that part of a device has its
> separate driver besides the driver for the main feature of the whole
> device.  The resources used by the sub-device is usually part of the
> resources of the parent device.  So it makes sense to put the node of
> sub-device beneathe the node of main device.  Shall we have a convention
> to mark such devices in device tree so that the sub-device can be
> scanned and probed as a standalone of_platform_device?
> 
> If "simple-bus" may cause confusion to do this job as it's not a bus
> actually, I propose to use "has-subdevice".

As Grant says, you're thinking about what drivers will do with things
rather than what the actual hardware setup is, which is what the
device tree should describe.

I see two sensible options for this situation:
	- Move the MDIO node to outside the gianfar MAC node.  I think
this is already done on some boards with gianfar?
	- Explicitly add the gianfar device to the list of things to
scan for of_platform subdevices.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

  parent reply	other threads:[~2009-01-07  2:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-05 10:27 The usage of compatible 'simple-bus' Li Yang
2009-01-05 19:20 ` Scott Wood
2009-01-06  1:43   ` David Gibson
2009-01-06  5:46     ` Li Yang
2009-01-06  6:35       ` Grant Likely
2009-01-06  7:01         ` Li Yang
2009-01-07  2:00       ` David Gibson [this message]
2009-01-07  3:26         ` Grant Likely
2009-01-07  3:51         ` Li Yang
2009-01-07 15:25           ` Scott Wood

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=20090107020006.GD13731@yookeroo.seuss \
    --to=david@gibson.dropbear.id.au \
    --cc=LeoLi@freescale.com \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@freescale.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).