Messages in this thread | | | From | Kevin Hilman <> | Subject | Re: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses | Date | Fri, 20 Aug 2010 17:10:00 -0700 |
| |
Grant Likely <grant.likely@secretlab.ca> 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |