Re: [PATCH v2 0/5] acpi/x86: s2idle: move Display off/on calls outside suspend (fixes ROG Ally suspend)

[Mario Limonciello <mario.limonciello@amd.com>]

>> It is perhaps best if I refer to what Denis and Derek told you about modern standby: focus on background downloads and proceed in that direction - the firmware really does fix the suspend/resume/reboot issues. You can also drop the asus-wmi patch (in submissions) as that will get dealt with soon enough.
> 
> I personally do not have a problem with making the next variant of
> this patch an RFC. But currently I think it has a good scope, so I
> would like to ask what other kernel maintainers think.

I don't think it's possible to have it both ways that the ordering is 
wrong AND the timing is wrong.

To me; this series is looking like a lot of bandaids to work around what 
behave as race conditions.   I'll leave some comments on the particular 
patches, but in the cover letter I want to see particularly patch 3 
tells me that this series isn't doing it right and you're getting lucky 
on the timing.

IoW if the call has been moved earlier but then you need to delay it to 
later was it really right to move it earlier?

Rather than littering the kernel with quirks for a buggy firmware
that the manufacturer is fixing I personally think it's a LOT better to 
invest the effort into getting the MCU updater ported to Linux and 
encourage users to update.

I started to add some code to fwupd [1] to at least parse the MCU 
version for Ally and Ally-X.  As this eventually lands higher level 
software could potentially communicate with the fwupd daemon over dbus 
to get this information and notify users that they need to update.

If we manage to get the whole update flow ported it could even work with 
the daemon to do the update.

https://github.com/fwupd/fwupd/tree/superm1/asus-hid