> > We first need to clarify the terminology as that seems to be the source of > the confusion to some extent at least. > > When I (or Alan presumably too) say "a subsystem", I mean a bus type, a device > type or a device class as represented by struct bus_type, struct device_type > and struct class, respectively. So "a subsystem callback" means the specific > callback defined in the given bus type, device type or device class object. > You can think about that as of "subsystem level" if that's easier. So that's > what we mean when we talk about subsystems, not the whole collection of drivers > and the code above them. Thanks, this makes it perfectly clear now. I will try to improve while communicating. So we have subsystems, power domains and drivers to consider. > > Now, say you have a bus type. Usually, the bus type's PM callbacks will run > device drivers' PM callbacks. Quite often they will do things to hardware > in addition to what the drivers do. But if your driver's .suspend_late() > depends on the runtime PM status of the device, then the bus type's .suspend() > needs to preserve that status. That is, it cannot do anything to the hardware > that may cause the runtime PM status of the device to become stale. That makes > the .suspend() somewhat special, doesn't it? I agree, but I can see why this should be a problem for each and every driver/bus. Do note that idea here is only to provide the option of allowing runtime PM callbacks to be executed as a part of the suspend_late -> resume_early sequence. It is not a rule, it will have to be decided for each subsystem/driver it they can benefit from this set up. > > Now I *guess* that your goal is something like "if that device has been > runtime suspended, don't touch it", which is a reasonable goal to have. I'd > like to implement something like that too, but I think that it needs to be done > differently. That is just a minor important part, but nice to have. Please have look at the recently submitted patch set, "[PATCH 0/5] PM: Enable option of re-use runtime PM callbacks at system suspend", I hope the "cover letter" will describe my intention better. > > Actually, my idea is to allow the subsystem-level .prepare() callback to let > the core know if the device needs to be handled during the given suspend/resume > cycle. It may be arranged, for example, so that if the subsystem-level (e.g. > bus type) .prepare() returns a positive number, the core will put the device > into a special list and it won't take it into consideration at all during the > whole cycle. > > Why this way? Because subsystems have much better ways to determine whether > or not it is necessary to access the device during the upcoming system > suspend/resume cycle than the core does. I am not sure I understand how this will solve my issues (except the minor "if that device has been runtime suspended, don't touch it" - thing). I will still have to have a complex power domain and still drivers/buses need wrapper functions around their the runtime PM callbacks to invoke them during system suspend, if they need them. In my view, I don't think your idea is conflict or can replace what I suggest. Both can improve the situation, but maybe for different scenarios. Kind regards Ulf Hansson > > Thanks! > > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
