[...] >>> >>> First off, how does the driver know that the device has to be in full >>> power for wakeup to work? >> >> Because the device is accessed as part of dealing with the wakeup. > > Yes, it is, In the working state of the system. In the system wakeup > case it may not be. > > Essentially, what happens then is that driver-provided interrupt > handlers don't run as a rule and system wakeup is triggered by the > low-level handler at the IRQ chip level. Next, the PM callbacks > invoked for the device are expected to clean up the wakeup status etc. > > Of course, power still is necessary for that to work, but it may be > not be in-band. That may be either in-band power used for normal > operations and provided through the interconnect used by the device or > it may be special wakeup power provided out-of-band. > > Also the wakeup signal itself may be an in-band device interrupt (like > the ones used for signaling IO events during normal operation) or it > may be a special wakeup signal (like PCI PME) in which case, from the > driver's perspective, the wakeup signaling is out-of-band. > > Usually, the driver doesn't know how this is set up for the particular > device in the particular platform and hence my question. :-) > > The case at hand seems to be when the wakeup power is in-band or the > wakeup signal is an in-band interrupt (in which case power needs to be > provided to the interconnect at least). Correct! > > If they both are out-of-band, the middle layer should know that, > because as a rule it will be involved in setting up both of them. > Otherwise, in principle, it should assume that in-band power needs to > be provided for wakeup to work and avoid turning things off if wakeup > is enabled. Agree! > >>> >>> Second, this requirement sort of implies that the device cannot go >>> into a low-power state during runtime suspend too, so it basically >>> remains stays at full power even when runtime-suspended. >> >> No, not really, because that depends on the current situation. >> >> An Ethernet device can surely go into a low power state, at runtime >> suspend, when the interface is down, for example. > > But then it is not expected to generate wakeup signals I suppose. Correct. > > [BTW, I wonder how it detects when the cable is connected again to it. > I know what happens in PCI NICs, but that clearly is not the case > here.] > > Well, anyway, it looks like the case when the device is > runtime-suspended right before system suspend and it is going to stay > suspended is not interesting here, because the state will be retained > whatever it is then. Correct. > > An interesting case seems to be when the device is not > runtime-suspended when system suspend triggers. > Yes. The principle is that the driver needs to runtime resume its device, if not already, during system suspend, as to be able to configure the in-band interrupt, then instruct the upper layers that the device needs to stay in its current power state. >>> >>> Does it then mean that the middle layer is expected to simply avoid >>> changing the power state of the device when enabled to wake up the >>> system, or is there more to that? In the former case, it may be >>> better to rename the flag to something along the lines of "don't >>> change power state if wakeup enabled". >> >> Yes, correct. >> >> I can try to clarify that in the description and unless you have a >> suggestion for a better name of the flag, I try to come up with >> something for that too. > > I was thinking about something like DPM_FLAG_IN_BAND_WAKEUP or similar. Perfect! > > But please note that there are cases in which the middle layer has > information on what power states to put devices into for wakeup to > work and IMO that should take precedence over the flag as a rule. Yeah, let me try to clarify that in the doc. [...] Kind regards Uffe
