Re: on the topic of of_device resources...

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Mon, 2008-05-05 at 01:44 -0700, David Miller wrote:
> 
> My plan on the sparc side is to remove the SBUS device type and bus
> entirely, as well as the EBUS layer I have.  All of it can use
> of_device nodes on of_platform_bus.  Even the DMA stuff just falls out
> of everything transparently because even that's all done via
> dev_archdata.
> 
> If you look at the SBUS layer, it's simply replicating OF device
> node objects for things that sit underneath SBUS bus nodes.  And
> it's like this because 32-bit sparc doesn't do the DMA stuff
> transparently like 64-bit sparc does.
>
> The of_platform_bus probing layer is extremely clean and I like
> how simple it is to write drivers using it.  The drivers look
> like normal PCI device drivers, both in terms of matching
> and in terms of resource/irq fetching.
> 
> I even use this for the core timeofday clock probing on sparc64.

Well, I agree it's nice and sleek for bus types you have complete
control on. The problem is when you start sharing with other
architecture :-) (well, other than powerpc & sparc !).

Which is why I might just stick to macio_device the way it is since
that's a totally local bus type, despite moving toward the different
approach I exposed for other things.

I think we need to continue supporting both approaches in the long run,
but that also means that low level parsers should as much as possible
remain based stictly on device node.

Now regarding using some kind of device for the timeofday clock probing,
well that's a different issue :-) We do need to get rid of our ppc_md.
stuff for that and move toward the new RTC infrastructure, which means
that our TODs will be proved like other devices.

Now, how so will depend on what TOD we have... i2c TODs (very common in
embedded) already have the necessary bits to be probed via the OF/i2c
bindings, creating i2c_device objects. Platform custom things like
PowerMac CUDA or PMU could be of_platform_devices. Etc...

Cheers,
Ben.