On Thu, Apr 26, 2007 at 11:00:25AM +0200, Arnd Bergmann wrote:

On Thursday 26 April 2007, Dale Farnsworth wrote:

quoted

quoted

Ok, I see your point there. But after looking at the i2c and net drivers,
I believe that they can easily be split into an architecture dependent
part that is either an of_platform_driver or a platform_driver, and
a common part that does not know about either of these.

Oh, it's certainly possible, but it doesn't seem desirable to me. Why
should the drivers carry the burden of supporting both platform_driver
and of_platform_driver interfaces?

The reason is that platform_devices are for stuff that fundamentally cannot
be probed but has to be hardcoded in some place.

The point about the of device tree is that it allows you to probe this
kind of device. This means you get automatic module loading based on the
device tree, and that the devices show up in sane locations in /sys.

I understand the benefits of the DT; that's not the issue.

Here we have platform devices common to MIPS and PowerPC platforms.
The drivers must continue to support the platform_driver interface
for MIPS platforms.  The question is, where should we put the glue
that transforms the DT info into the platform_driver format?

You seem to suggest putting the ethernet-related glue into
drivers/net/mv643xx_eth.c.  That's bogus, IMHO. The base driver
shouldn't have to accommodate every arch-specific interface.
(I know OF isn't strictly arch-specific, but it's far from universal.)
I put this glue into arch/powerpc/sysdev/mv64x60.c. I still don't see
the benefit of moving it into the drivers.

-Dale