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

Mario Limonciello
2024-09-23T15:57:06Z

>> 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.