on the topic of of_device resources...

David Miller davem at davemloft.net
Mon May 5 18:44:05 EST 2008

From: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Date: Mon, 05 May 2008 18:26:11 +1000

> Well, we aren't totally clear as to whether we'll use of_device much or
> not in the long term. For bus types that already have their own
> descendant of struct device (such as PCI, but also i2c, USB, etc...) it
> makes little sense to create a "special" version with OF device...
> That leaves platform devices, and there, experience has shown that it's
> not very practical neither when a driver is shared between powerpc and
> some other non-OF arch.
> So we are trying to move toward a slightly different approach: Any
> device can optionally be linked to a device_node (via dev_archdata), and
> we provide "constructors" to build the various kind of struct device
> descendants based on the device nodes.

I see, thanks for the info.

> This is in no way something done though. As you may have noticed,
> macio_device is still around, though on the other hand, we have code to
> build the PCI tree from the ground up straight off the OF nodes (that
> you may want to use too at one point ...) though it's not using the
> "constructor" approach. Some work hsa been done in the i2c layer to
> create i2c devices based on device nodes, and there are other areas like
> that.

I already build the PCI device tree on sparc64 strictly using
the OF device tree. :-)

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

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.

More information about the Linuxppc-dev mailing list