Re: [PATCH v4 0/2] hid-asus: asus-wmi: refactor Ally suspend/resume

[Antheas Kapenekakis]

On Tue, 25 Mar 2025 at 00:44, Luke D. Jones <luke@xxxxxxxxxx> wrote:
>
> On 25/03/25 03:46, Antheas Kapenekakis wrote:
> > On Mon, 24 Mar 2025 at 11:34, Luke D. Jones <luke@xxxxxxxxxx> wrote:
> >>
> >> On 24/03/25 21:11, Antheas Kapenekakis wrote:
> >>> On Mon, 24 Mar 2025 at 02:41, Luke D. Jones <luke@xxxxxxxxxx> wrote:
> >>>>
> >>>> On 24/03/25 00:41, Antheas Kapenekakis wrote:
> >>>>> On Sun, 23 Mar 2025 at 03:34, Luke Jones <luke@xxxxxxxxxx> wrote:
> >>>>>>
> >>>>>> This short series refactors the Ally suspend/resume functionality in the
> >>>>>> asus-wmi driver along with adding support for ROG Ally MCU version checking.
> >>>>>>
> >>>>>> The version checking is then used to toggle the use of older CSEE call hacks
> >>>>>> that were initially used to combat Ally suspend/wake issues arising from the MCU
> >>>>>> not clearing a particular flag on resume. ASUS have since corrected this
> >>>>>> especially for Linux in newer firmware versions.
> >>>>>>
> >>>>>> - hid-asus requests the MCU version and displays a warning if the version is
> >>>>>>      older than the one that fixes the issue.
> >>>>>> - hid-asus awill also toggle the CSEE hack off, and mcu_powersave to on if the
> >>>>>> version is high enough.
> >>>>>>
> >>>>>> *Note: In review it was requested by Mario that I try strsep() for parsing
> >>>>>> the version. I did try this and a few variations but the result was much
> >>>>>> more code due to having to check more edge cases due to the input being
> >>>>>> raw bytes. In the end the cleaned up while loop proved more robust.
> >>>>>>
> >>>>>> - Changelog:
> >>>>>>      + V2: https://lore.kernel.org/platform-driver-x86/20250226010129.32043-1-luke@xxxxxxxxxx/T/#t
> >>>>>>        - Adjust warning message to explicitly mention suspend issues
> >>>>>
> >>>>> How did the testing go with this one, especially with mcu_powersave 0?
> >>>>
> >>>> Appears to be good. Checked a few reboots with powersave off - it is
> >>>> setting on as I expect every time. Did modules unload/load also. And
> >>>> tested with it set off after boot plus suspend resumes.
> >>>
> >>> Did you test suspends with mcu_powersave to 0 and rgb on? I had a few
> >>> issues you can reference the previous version for and I want to see if
> >>> you have them.
> >>>
> >>> Even with powersave set to 1, the RGB does not fade anymore without the quirk
> >>
> >> Yes I tested every scenario I could think of. I don't think the fade is
> >> something to worry about
> >
> >  From my testing, I got it to flash random colors and not disconnect
> > properly, so if you really want to remove it, you should make sure to
> > test the version that disables the quirk properly first.
>
> Like I said I have. This "random colours" sounds like a userspace issue
> such as the solid/static colour not having set/apply/save after it.
> There is zero in this patch to cause anything like that.

No userspace software was running at the time and hhd will always do
b3/b4/b5 at least once. It looks like a firmware bug that is triggered
because of the reorder.

> 1` hour later: I'm currently doing a very heavy refactor of the
> hid-asus-ally driver and it looks like I've solved both the fade (a very
> noticeable improvement), and the random colour issue. I'll do my best to
> get this done by the middle of weekend (I'm UTC+12) so you can have a
> test - to save you some time I'll have your patch series on top with
> conflicts solved.
>
> >> seems like it happening at all previously was
> >> just due to suspend being held up for a bit longer and now that the hack
> >
> > Yes, because Windows does not enter s0i3 instantly, so some devices,
> > like the Ally units, like the Go S, rely on that for different
> > purposes. 500ms is perfectly fine for both, and since it happens
> > during suspend and not resume, provided that the screen has been
> > turned off, it is transparent. (The Go S gets an APU hang due to very
> > aggressive TDP tuning; a delay after the sleep entry call and
> > userspace suspend lets the VRMs cool off a bit)
> >
> >> is disabled for new FW, it relies fully on Linux suspend (async?
> >> Honestly it's never been fully clear how async it really is).
> >
> > The call is at the wrong place unfortunately. That's about it
> >
> >> I'd rather the faster suspend/resume. And so far I've heard no
> >> complaints (although my userbase is smaller than bazzites).
> >
> > Have you deployed the V4 though? Because the behavior with the quirk
> > is fine. WIthout, it is soso.
>
> I have. I agree it was... meh. But the hid-asus-ally rewrite is solving
> a lot of issues now, and I'm thoroughly testing every scenario and
> applying a lot of lessons learned.
>
> To be clear: Right now this current series is good. The issues
> encountered are solved in hid-asus-ally, so I'm comfortable with merging
> this upstream and I'll try crack on with the new driver.
>
> >> Cheers,
> >> Luke.
> >>
> >>> Antheas
> >>>
> >>>> Very much hope this is the end of that particular saga, and with
> >>>> bazzites help we can hopefully get everyone on November MCU FW or later,
> >>>> then finally remove the hack completely this year.
> >>>>
> >>>> A small side note - I expect ASUS to fully reuse the X hardware, or at
> >>>> least the bios/acpi/mcu-fw for that new windows handheld they've doing,
> >>>> so fingers crossed that they actually do, and there will be nomore
> >>>> suspend issues with current kernels plus this patch.
> >>>>
> >>>> Cheers,
> >>>> Luke.
> >>>>
> >>>>>>        - Use switch/case block to set min_version
> >>>>>>          - Set min_version to 0 by default and toggle hacks off
> >>>>>>      + V3
> >>>>>>        - Remove noise (excess pr_info)
> >>>>>>        - Use kstrtoint, not kstrtolong
> >>>>>>        - Use __free(kfree) for allocated mem and drop goto + logging
> >>>>>>        - Use print_hex_dump() to show failed data after pr_err in mcu_request_version()
> >>>>>>        - Use pr_debug in set_ally_mcu_hack() and set_ally_mcu_powersave() plus
> >>>>>>          correct the message.
> >>>>>>      + V4
> >>>>>>        - Change use_ally_mcu_hack var to enum to track init state and
> >>>>>>          prevent a race condition
> >>>>>>
> >>>>>> Luke D. Jones (2):
> >>>>>>      hid-asus: check ROG Ally MCU version and warn
> >>>>>>      platform/x86: asus-wmi: Refactor Ally suspend/resume
> >>>>>>
> >>>>>>     drivers/hid/hid-asus.c                     | 111 ++++++++++++++++-
> >>>>>>     drivers/platform/x86/asus-wmi.c            | 133 +++++++++++++++------
> >>>>>>     include/linux/platform_data/x86/asus-wmi.h |  19 +++
> >>>>>>     3 files changed, 222 insertions(+), 41 deletions(-)
> >>>>>>
> >>>>>> --
> >>>>>> 2.49.0
> >>>>>>
> >>>>
> >>
>