On Sunday 14 March 2010, Alan Stern wrote: > On Sun, 14 Mar 2010, Rafael J. Wysocki wrote: > > > > You know, maybe we should allow bus types to use both the old and new > > > interfaces. It would make life easier for other subsystems in addition > > > to i2c. > > > > > > This doesn't mean that the core would end up calling two sets of > > > suspend routines. If the bus type uses legacy routines then all the > > > non-runtime entries in the pm_ops structure would be empty. > > > > > > The changes to the PM core necessary to do this are quite small. > > > > Not really. The detection that the particular callback is not present happens > > in pm_op(), while the decision which framework to use is made at the > > device_[suspend|resume]() level. > > All you have to do is change the "else if" lines in > device_[suspend|resume]() to "if". Then, if a bus type implements both "new" and "old" callbacks, we'll end up calling both. Not nice. > > > Does it seem like a reasonable thing to do? > > > > Well, if someone spends time on implementing new callbacks for a bus type, > > writing them in such a way that they will call the "legacy" callbacks from > > drivers if necessary is not really a big deal IMO. > > Sure. But suppose you _don't_ want to spend the time implementing new > callbacks to replace the existing legacy suspend and resume methods, > whereas you _do_ want to implement runtime PM. Runtime PM forces the > bus type to have a pm_ops member, Which is very much on purpose, because the legacy suspend and resume have no idea about the runtime stuff. > which as you point out, will prevent the legacy methods from being called. Yes, that's intentional. That said, I think we might modify the generic callbacks in generic_ops.c to call the drivers' legacy callbacks if the "new" ones are not defined. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html