Grant Likely <grant.likely@xxxxxxxxxxxx> writes: >>> 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. > > Alright, I can agree to that. I do agree that the runtime override is > far and away better than the weak symbol approach. However, there > needs to be some very clear rules in place for users of the override, > namely that users must understand that they are stewards of the > platform_bus_type, and must take care to preserve the default > behaviour for "uninteresting" devices. Completely agree here. Any overrides of the dev_pm_ops functions that do not also call the pm_generic_* functions (or their equivalents) should be suspect. I'll post a proposal for a runtime override shortly. > Also, the expectation should be that it is a temporary measure until a > better abstraction is implemented. It might be that a separate > bus_type is the way to go (if the multiple driver registration problem > can be solved) or it might be a way to differentiate pm_ops either > per-device or per-parent. I'm not sure, but I'm starting on an OMAP > project soon, so I may very well end up working on this. Yes, I'll be glad to work on this too, but first I need to get through reviewing the backlog of all the OMAP drivers we're converting to runtime PM. 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
