On Fri, Jun 25, 2010 at 3:58 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > Grant Likely <grant.likely@xxxxxxxxxxxx> writes: >> Yes, I've got patches which merge of_platform_bus_type with the >> platform bus. This was an easy decision to make because the >> of-specific bits (specifically, matching an of_device_id table with a >> device tree node) are applicable to all bus types; i2c, spi, mdio, >> platform, etc). The needed OF data structures have been moved into >> struct device and struct device_driver so that of_platform_bus_type no >> longer has anything different. >> >> The drivers still need to care about OF when extra platform data needs >> to be extracted from the DT node, but for IRQs and register ranges it >> is automatic. > > Does that mean the drivers are still doing platform_get_resource() for > either platform devices or OF devices, or are does the driver have to > know which bus it was on and call accordingly. It's the latter that I > want to stay away from. platform_get_resource() works for OF and non-OF platform devices with no extra code needed in the OF case. It's the other data that requires special code because it is provided in the device tree instead of in a platform_data structure. A driver that normally uses platform_data will need extra code early in the probe hook to go and parse the device tree and populate the private data structures accordingly. This behaviour has to be handled in the driver because every driver uses a different platform_data structure. It cannot be generic code. The rest of the driver can remain untouched. In the old (bad) way, the bus type was entirely different, and drivers used by both platform_bus_type and of_platform_bus_type needed to have entirely separate device_driver structures and probe() hooks for each bus type. [...] >> So, instead of having all the platform_bus_type devices as children of >> the "platform" device (/sys/devices/platform/*), you could set the >> omap devices to be children of an omap bus device >> (/sys/devices/omap/*). Different busses can also implement different >> behaviour by using a different parent device. For example: >> >> /sys/devices/platform >> /sys/devices/omap-bus-a >> /sys/devices/omap-bus-a/omap-bus-b >> >> Thoughts? > > Hmm, I like this idea. This is certainly worth exploring as a first > pass. > > Thanks for the idea, :-) 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
