On Mon, Sep 11, 2023 at 10:23 PM Mario Limonciello <mario.limonciello@xxxxxxx> wrote: > > On 9/11/2023 13:34, Rafael J. Wysocki wrote: > > On Wed, Sep 6, 2023 at 9:16 PM Mario Limonciello > > <mario.limonciello@xxxxxxx> wrote: > >> [cut] > > > > IMV, the underlying issue all boils down to the platform firmware > > inadequately describing the behavior of the system to the OS. > > Specifically, had it provided a _S0W returning 0 for the Root Port(s) > > in question, wakeup signaling would have worked (or else there would > > have been a defect in the kernel code to be addressed). > > I think you're right. I'll try and get BIOS guys to provide a test BIOS > to prove this direction is correct. > > It wouldn't help all the machines already in the field but if it can be > done without harm to Windows maybe future SoCs could use it. > > > Instead, it > > decided to kind-of guide Windows in the "right" direction through PEP > > constraints which doesn't have the same effect on Linux and honestly > > I'm not even sure if it is a good idea to adjust Linux to that. > > > > What is the worry with bringing Linux in this direction (using constraints)? First off, ostensibly the purpose of the constraints is to indicate to Windows when it can attempt to put the system into the deepest power state. Specifically, AFAICS, Windows is not expected to do so when the current power state of a given device is shallower than the relevant constraint. Consequently, a constraint of D0 means that effectively Windows is expected to ignore the given device as far as Modern Standby goes. In any case, this has no bearing on the behavior of suspend-to-idle in Linux. Now, there may be other undocumented side-effects of setting a constraint of D0 in Windows, but it is generally risky to rely on such things. Second, it is not entirely clear to me whether or not the future versions of Windows will continue to use the constraints in the same way. > My main hope is that by generalizing this fundamental difference in how > Windows and Linux handle Modern Standby / suspend-to-idle we can avoid > other future bugs. There is a fundamental difference between Modern Standby and suspend-to-idle already, as the former is opportunistic and the latter is on-demand. They can both follow the exact same set of rules.