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

[Grant Likely]

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:
>>>> http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg31161.html
>>>
>>> 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
behaviour?"

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.

Cheers,
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/