Grant Likely <grant.likely@xxxxxxxxxxxx> writes: [...] >>> >>> My fears on this point may very well be unfounded. This isn't the >>> hill I'm going to die on either. Show me an implementation of driver >>> sharing that is clean and prove me wrong! :-) >> >> IMHO, simply overriding the few dev_pm_ops methods was the cleanest and >> simplest. >> >> Since we seem to be in agreement now that the a new bus may not the >> right abstraction for this (since we want it to be completely >> transparent to the drivers), I'll go back to the original design. No new >> bus types, keep the platform_bus as is, but simply override the few >> dev_pm_ops methods I care about. This is what is done on SH, >> SH-Mobile[1] and my original version for OMAP that started this >> conversation. >> >> Yes, the weak-symbol method of overriding is not scalable, but that's a >> separate issue from whether or not to create a new bus. I have a >> proposed fix for the weak which I'll post shortly. > > Okay. > > One constraint remains though: If you can override the dev_pm_ops on > a per-device or per-device-parent basis, then you've got my support. hmm, a new requirement?, and one that would require some significant changes to the driver model. Currently, dev_pm_ops for a bus applies globally to *all* devices on that bus (or class or type) and changing that would require changing the platform_bus code to start having per-device (or per-parent-device) checks. > If the override (even when fixed to work at runtime) applies to every > device on the platform_bus_type, then I'll nack it. /me can't help but wonder why the OMAP implementation is getting all the negative attention while the other identical implementations are already upstream. > My concern here is that the SoC or platform support code doesn't get > to "own" the platform_bus_type. Well, I'm not proposing that here. This "feature" already exists in mainline (albeit using the less-than-optimal weak symbol approach.) All I'm proposing is fixing it to make it multi-arch friendly. If you think this behavior should be changed to non global, that should be done a separate series since it is not directly related to runtime PM support for a given platform, IMO. > Other drivers/code can register their own set of > platform_devices, which may also need to perform their own dev_pm_ops > override. IMHO, we should deal with such hypothetical, future problems *if* they arise down the road. > If the override is global to the platform_bus_type, then the model > will not scale. It will not scale any more (or less) than the current functionality of the driver model which handles this globally. Again, if scalabilty becomes a problem down the road, lets fix it then. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
