RE: [PATCH 2/2] platform/x86: asus-wmi: Refactor Ally suspend/resume

[Antheas Kapenekakis <lkml@antheas.dev>]

Hi Luke,
setting MCU powersave too close to the boot-up sequence can cause the
controller of the original Ally to malfunction. Which is why you created
this little init sequence in which you call CSEE manually. In addition,
MCU powersave (which is called Extreme Standby in Windows and you named
incorrectly in asus-wmi), causes a very large 8 second delay in the resume
process. It should under no circumstance be set enabled by default.

Users that want it can enable it manually. Following, distributions that
want it and lack the appropriate configuration interface can use a udev
rule with an 8 second delay to enable it, and then, the udev rule should
first check if mcu_powersave is disabled before enabling it. This is
because writing to it even with the same value causes an issue regardless.

Therefore, please remove both parts of it from the second patch in your
series and produce a v2, which contains no hints of CSEE. When you do:

Suggested-by: Antheas Kapenekakis <lkml@antheas.dev>

Following, when you do finish the new Asus Armoury patch series, please
rename MCU powersave to extreme standby, and add a suggested-by in the
appropriate patch. Since to avoid user confusion, the names should match
their windows branding.

During our testing of the controller, we found that the lack of a delay
causes the RGB of both the Ally and the Ally X to malfunction, so this is
a small nack for me (the old quirk is preferable in that regard). But then
again, this patch series is not getting anywhere close to our users even
if it is accepted, so you can do as you wish (given appropriate attribution).

Best,
Antheas