On 09/16/2013 10:47 AM, Mika Westerberg wrote: > I'm actually thinking that it is probably better now if we don't touch the > client runtime PM at all in the I2C core. > > I proposed a less intrusive solution in this same thread where we power the > I2C controller briefly at the client ->probe() (In order to have all the > ACPI power resources etc. and the controller on) and let the client driver > handle their own runtime PM as they do currently. > > Do you think that would work better wrt. fimc-isp-i2c driver? That would be no different for this particular driver, as long as the I2C bus controller is activated right before the I2C client's probe(). In general I would expect such additional device activation not to be harmful. For that particular driver I'm going to prepare patches to ensure that the I2C bus controller device and its driver is registered only when a driver it depends on has initialized. This should have been ensured right from the beginning. So don't need to worry about this particular case. I'm just not sure what other devices could be similarly affected. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
