Hi Denis, thank you for taking the time to test the patch. First I want to give some context. I have tested variants of this patch on 6.11rc5 and linux-pm/bleeding-edge on both an Ally X and a Legion go. I experienced 0 sleep failures on both of them throughout my whole series of testing, on all variants of the patch. I did not test 6.11 final. So I hope you did A/B test, as it is not clear from your email. We have had a lot of issues with new kernels and suspend, so please make sure to test 6.11 stock. The ACPI error in the s2idle report for the _DSM is normal, Asus left a lid sensor call that goes nowhere below the CSEE call that turns off the MCU. I am not that well versed in s2idle traces, but from what I am seeing is that your controller suspends beautifully, but some suspends fail due to a PCI error? Then you have "[Errno 16] Device or resource busy" but no accounting of which device that is. All this patch does is move CSSE to happen outside the suspend sequence, whereas before it was done *twice* within the suspend sequence, @Mario what are your thoughts? The controller is expected to disconnect and reconnect to the device, we are not trying to avoid that. We plan to do a lot more thorough testing next week on Bazzite (on all devices), however our kernel maintainer is feeling under the weather so it will take a couple more days for that to start. Also, a small comment on this new firmware. This patch has merit regardless of what Asus does with the ROG Ally, it is both a feature and bug fix contribution. I would like to see suspend in Linux become a lot more modern, as it is a feature we are often asked about. Users want to be able to download games suspended for example. The Switch can do it, the Playstation 5 can do it, but uh Linux cannot? It will not cause regressions regardless of what Asus does, as this is making Linux mimic Windows more. Then, to move on to your other concern. Hopefully, you conducted these tests with a stock firmware. I think you did. Secondly, to me, requiring a firmware update + kernel quirk + software quirk (as extreme mode will be MCU version dependent) is something that I do not find to be a very satisfactory solution. In any case, we are happy to hold this patch out-of-tree for our users with older firmware and then tack on whatever else is required for the newer firmware. I will post an updated version of the patch later today, although it is functionally identical. Antheas
