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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
