On Tue, Dec 14, 2010 at 02:10:58PM -0500, Alan Stern wrote: > I see. It sounds like you're really saying that new devices default to > the wrong runtime state. If pm_runtime_init() would set new devices to > RPM_ACTIVE instead of RPM_SUSPENDED then this problem wouldn't arise. > Children could do whatever they want, and even if the parent's driver > was totally ignorant of runtime PM, it would work out. In this case that's the desired behaviour but I worry that it'd break some other use case (eg, keeping a parent awake because there was an unclaimed device sitting around). When I've been working with the runtime PM subsystem before I've thought that it might be nice to have a specific RPM_UNINITIAZLIZED state which would generally get out of the way. It might be a bit clearer than the current situation conceptually but I've never felt I had a firm enough grasp on what was going on to really say, everything always feels more complicated than I feel it should if I understood it properly. Thinking about it in the case of I2C we probably also want to mark the device as ignoring its children when it registers as an I2C controller, while an I2C controller that does runtime PM will probably figure this out for itself it would save a bit of effort. -- 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
