OCP vs. platform_device (was Marvell 64360/64340 GigE driver for MIPS and PPC....)

[Mark A. Greer]

Forwarding to a wider PPC audience...

Mark
--

Dale Farnsworth wrote:

On Fri, Oct 08, 2004 at 08:25:18AM -0400, Brian Waite wrote:

>> Just because I am a bit unclear as to what the concensus let's outline again 
>> the alternative as I see them and see which makes the most sense.
>> 
>> 1) Move ocp to generic code and move MIPS to ocp.
>>  - Not good because there are too many uses of platform_devices and ocp 
>> appears to be an inadequeate solution
>> 
>> 2) Move PPC, or at least Marvell PPC platforms, to the platform_device. 
>>  - I think the above argument can apply.
>> 
>> 3) Keep MIPS on platform_device and PPC on ocp and provide glue logic to stick 
>> either interface to the ethernet driver.
>>  - Not the cleanest solution as it still keep 2 independent interfaces that 
>> essenitally do the same thing in the tree, but it hurst everyone the least 
>> amount to make work.
>> 
>> Of those three options, I am thinking 3 is the way to go. If we can agree on 
>> that then we can start working out the details.
>  
>

I prefer a variation on option 2.  Only support platform_device on the
Marvell ethernet driver and support both OCP and platform_device drivers
on Marvell PPC platforms.

When I added ethernet support for redwood5 and redwood6 in 2.6, I used
the arm smc91x driver, which has a platform_device interface.  I found
it easier to add the platform_device calls to the redwood platform
files than to add an ocp interface to the smc91x driver.  Check out
arch/ppc/platforms/4xx/redwood5.c for a simple platform_device example.

More important than ease of implementation is that I think OCP has
already lost out to platform_device.  (I raised a ruckus on #mklinux
a few months back when I suggested this. :-)  As others have said,
they perform essentially the same function* and platform_device is
already supported in multiple architectures.  OCP must die, but I
prefer a slow death. :-)  We can transition from supporting OCP to
platform_device one driver at a time, by having platforms support
both during the transition.

This doesn't mean I'm thrilled with platform_device.  Shoehorning
everything into a struct resource is ugly.  I also think it needs
to better describe device hierarchies (which OCP doesn't do today
either), which will be a major change.  But platform_device is as
good as OCP now.  The pros and cons between them are nits, trumped
by platform_device's cross-architecture support.

-Dale

* BTW, for the PPC folks, I also think bi_recs and the OF device tree
serve nearly the same function.  IMHO, we should use the same mechanism
to pass device info to the kernel that the kernel uses to pass device
info to the drivers.  But that's extraneous to this discussion, and I'm
not proposing that we do anything on this now.