On Saturday, December 18, 2010, Mark Brown wrote: > On Sat, Dec 18, 2010 at 01:54:57PM +0100, Rafael J. Wysocki wrote: > > On Saturday, December 18, 2010, Mark Brown wrote: > > > > SPI and platform (the first two buses I looked at) both seem to have > > > legacy suspend operations too? Clearly the bus would need to provide an > > > op to invoke the legacy call but the logic which prioritises the pm_ops > > > over the legacy operation is generic. > > > Well, the problem with that is the driver would need to tell the generic call > > what the legacy routine is and there's no, er, generic way to do that. > > > In the i2c case, for example, there is struct i2c_driver that contains the > > ->suspend() and ->resume() pointers, so the bus type driver _knows_ how to > > get there, but the PM core doesn't have this information. > > Sure, but this could be readily accomplished by providing bus > legacy_suspend() and legacy_resume() operations that the generic code > could use to do the actual call. First, there already are ->suspend() and ->resume() callbacks in struct bus_type which are regarded as "legacy". The PM core uses those as appropriate in drivers/base/power/main.c . Second, the situation at hand is that the bus type implements dev_pm_ops, but the driver doesn't. Now, pm_generic_suspend() is called with a struct device pointer, so it would have to go back to dev->bus, find the ->legacy_suspend() callback (as opposed to ->suspend(), which also is legacy, but is called by the PM core instead). May I call that confusing? > This would save them all implmeneting > essentially the same decision making code for all the various different > PM operations - the only bit that differs between buses is going to be > the actual process for calling the legacy API. > > Like I say, I'm not sure if it's actually worth it. Well, I don't really think so. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm