Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

On Wed, May 27, 2009 at 10:31:47PM -0700, David Miller wrote:
> From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
> Date: Thu, 28 May 2009 14:47:32 +1000
> 
> > The conceptual problem becomes apparent when you consider things like
> > i2c.  The devtree is the obvious source to discover what i2c device
> > are present, but they need to be instantiated as i2c devices on the
> > i2c bus, not of platform devices.
> 
> Sure, but there is no reason there can't be an of_platform driver
> for those i2c devices.  And such instantiated devices get propagated
> either instantly to the parent, or later when the parent controller
> probes.

Right, but the point is the bus info is trying to do two things here -
one is to supply stuff that's actually common to the bus interface,
the other is the probing logic.  That's usually connected to the bus
interface, but in the case of non-probeable basses on a system with a
devtree, that's no longer the case.  As soon as the bus has some
common logic that's really related to the bus interface regardless of
platform, then you start losing to use of_platform instead of a
specific bus structure because you have to duplicate that -
essentially having both OF and non-OF variants of however many busses
we need.

I think its saner instead to have the device model stuff only
represent stuff that's actually related to the bus interface, and
separately instantiate things into those busses from an OF tree
traversal.  I think this can be made as convenient as the current
setup for OF systems, though obviously I'll have to get around to
actually implementing it to be sure.

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