Re: [PATCH] platform: Facilitate the creation of pseduo-platform busses

From: Grant Likely
Date: Thu Aug 05 2010 - 19:16:40 EST

On Thu, Aug 5, 2010 at 9:57 AM, Kevin Hilman
<khilman@xxxxxxxxxxxxxxxxxxx> wrote:
> Patrick Pannuto <ppannuto@xxxxxxxxxxxxxx> writes:
>> On 08/04/2010 05:16 PM, Kevin Hilman wrote:
>>> Patrick Pannuto <ppannuto@xxxxxxxxxxxxxx> writes:
>>>> Inspiration for this comes from:
>>> Also, later in that thread I also wrote[1] what seems to be the core of
>>> what you've done here: namely, allow platform_devices and
>>> platform_drivers to to be used on custom busses.  Patch is at the end of
>>> this mail with a more focused changelog.  As Greg suggested in his reply
>>> to your first version, this part could be merged today, and the
>>> platform_bus_init stuff could be added later, after some more review.
>>> Some comments below...
>> I can split this into 2 patches.
> Yes, I think that would be better.
>> Was your patch sent to linux-kernel or just linux-omap? I'm not on linux-omap...
> That thread was on linux-arm-kernel and linux-omap
>>>> [snip]
>>>> Which will allow the same driver to easily to used on either
>>>> the platform bus or the newly defined bus type.
>>> Except it requires a re-compile.
>>> Rather than doing this at compile time, it would be better to support
>>> legacy devices at runtime.  You could handle this by simply registering
>>> the driver on the custom bus and the platform_bus and let the bus
>>> matching code handle it.  Then, the same binary would work on both
>>> legacy and updated SoCs.
>> Can you safely register a driver on more than one bus? I didn't think
>> that was safe -- normally it's impossible since you're calling
>> struct BUS_TYPE_driver mydriver;
>> BUS_TYPE_driver_register(&mydriver)
>> but now we have multiple "bus types" that are all actually platform type; still,
>> at a minimum you would need:
>>       struct platform_driver mydrvier1 = {
>>               .driver.bus = &sub_bus1,
>>       };
>>       struct platform_driver mydrvier2 = {
>>               .driver.bus = &sub_bus2,
>>       };
>> which would all point to the same driver functions, yet the respective devices
>> attached for the "same" driver would be on different buses. I fear this might
>> confuse some drivers. I don't think dynamic bus assignment is this easy
>> In short: I do not believe the same driver can be registered on multiple
>> different buses -- if this is wrong, please correct me.
> It is possible, and currently done in powerpc land where some
> drivers handle devices on the platform_bus and the custom OF bus.

As of now, the of_platform_bus_type has been removed. It was a bad
idea because it tried to encode non-bus-specific information into
something that was just a clone of the platform_bus. Drivers that
worked on both had to be bound to both busses. I do actually have
code that automatically registers a driver on more than one bus, but
it is rather a hack and was only a temporary measure.

The relevant question before going down this path is, "Is the
omap/sh/other-soc behaviour something fundamentally different from the
platform bus? Or is it something complementary that would be better
handled with a notifier or some orthogonal method of adding new

I don't have a problem with multiple platform_bus instances using the
same code (I did suggest it after all), but I do worry about muddying
the Linux device model or making it overly complex. Binding single
drivers to multiple device types could be messy.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at