On Fri, Aug 20, 2010 at 6:10 PM, Kevin Hilman
Nope! Not a new requirement; this is the issue that this entire
thread has been about. Hijacking the entire platform_bus_type
behaviour for a particular bus is the wrong thing to do because there
are other users in the same system.
I'm not opposed to modifying the platform_bus_type to support the use-case.
OMAP is not getting singled out. This applies to all the implementations.
Oops, I didn't phrase that very well. What I meant was that SoC or
platform support code must not be allowed to "own" or hijack the
platform_bus_type for it's own purposes. What I wrote sounds like I
was suggesting that as a good thing.
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.
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.