Re: [RESEND PATCH 0/5] platform/x86: bitland-mifs-wmi: MIFS v2 firmware support (Xiaomi Book Pro 14 2026)

[Eason]

Hi Yuming,

I would like to add a third affected machine to this report: the REDMI
Book Pro 14 2026 (board TM2426, Core Ultra 5 338H, Panther Lake), BIOS
RMAPT4B0P0909 (2026-05-21), EC firmware 1.9, originally running
7.2.8-zen1-2-zen.

It shows the same MIFS v2 firmware behaviour you describe, and your series
addresses the two things that make this laptop unusable for suspend today.

1) Suspend (s2idle) is aborted with -EINVAL by the driver's suspend hook.
   Every attempt ends like this:

     PM: suspend entry (s2idle)
     bitland-mifs-wmi B60BFB48-3E5B-49E4-A0E9-8CFFE1B3434B-4: PM: dpm_run_callback(): bitland_mifs_wmi_suspend [bitland_mifs_wmi] returns -22
     bitland-mifs-wmi B60BFB48-3E5B-49E4-A0E9-8CFFE1B3434B-4: PM: failed to suspend: error -22
     PM: Some devices failed to suspend, or early wake event detected
     systemd-sleep: Failed to put system to sleep. System resumed again: Invalid argument

   /sys/power/suspend_stats on this machine:

     failed_suspend   4
     last_failed_dev  B60BFB48-3E5B-49E4-A0E9-8CFFE1B3434B-4
     last_failed_errno -22
     last_failed_step suspend
     success          0

   Since then I set up a disk swap file and verified all three sleep paths
   locally with a minimal one-file change that follows the approach of your
   patch 1/5 (never propagate the perf-mode query error from the suspend
   hook), applied on top of a 7.2.9 tree (Arch linux-zen packaging of 7.2.9:
   vanilla 7.2.9 plus the zen patchset):

     * s2idle works again:

         PM: suspend entry (s2idle)   18:13:51
         PM: suspend exit             18:13:57
         /sys/power/suspend_stats: success=1, failed_suspend=0

     * hibernation works and the session is restored (same boot id before
       and after; ~63-94 s offline including firmware POST):

         systemd-hibernate.service: Finished System Hibernate
         systemd-sleep: Successfully thawed unit 'user.slice'

     * closing the lid does the right thing as well, with logind configured
       for HandleLidSwitch=suspend-then-hibernate and HibernateDelaySec=1h:

         Lid closed                                 18:31:00
         PM: suspend entry (s2idle)                 18:31:00
         PM: suspend exit                           18:32:01
         sleep operation 'hibernate'                18:32:02
         PM: hibernation: hibernation exit          18:33:47
         (same boot id before and after the whole sequence)

   I am happy to send the one-file diff, the full logs and the /sys/power
   settings, or to test a revised version of this series.

2) platform_profile registration fails, exactly as in your report:

     platform_profile: Failed to get profile for handler bitland-mifs-wmi
     platform_profile: Failed to get profile for handler bitland-mifs-wmi
     platform_profile: Failed to get profile for handler bitland-mifs-wmi

   /sys/class/platform_profile does not exist, so power-profiles-daemon
   cannot read or set any profile.

The firmware side matches your analysis as well - the missing ECON symbol
shows up 40 times during a single boot:

  ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.LPCB.Q_EC._STA.ECON], AE_NOT_FOUND
  ACPI Error: Aborting method \_SB.PC00.LPCB.Q_EC._STA due to previous error (AE_NOT_FOUND)

Both bitland_mifs_wmi and redmi_wmi are loaded on this machine, as in [1].

One difference to the unit you tested: TM2426 does expose an ACPI lid
device (PNP0C0D:00) and an input device "Lid Switch" with the SW_LID bit
set (capabilities/sw = 1), so patch 4/5 may not be needed on this model.
I have now verified that lid events do arrive here: logind logs "Lid closed."
and performs the configured sleep action (see the sequence above). The
firmware still reports a bogus lid state once per resume ("ACPI: button:
[Firmware Bug]: Unexpected lid state reported by firmware"), which does not
prevent the lid action from working.

For completeness, one more observation from this board (possibly
unrelated to MIFS): ACPI init takes about 6 seconds here. initcall_debug
attributes it to ACPI object evaluation - e.g. 0.4-0.6 s per power
resource, ~2.7 s in acpi_processor_driver_init and ~4.1 s in acpi_init.
If the ECON/_STA problem is involved in that as well, I am happy to
collect whatever data helps.

I can provide further evidence (acpidump, full dmesg, DSDT disassembly of
the WMAA method and the QFAN-related objects, longer suspend_stats) or run
any test instructions you have. I can build and test kernels locally (the
verification above was done with a hand-built 7.2.9 plus a 10-line diff),
so I am also happy to test revised versions of this series, including on
mainline, and report back.

Thanks a lot for working on this - suspend being blocked was the biggest
usability problem on this laptop.

Note: the local testing and the preparation of this report were done with
the assistance of a local AI assistant (DeepSeek Harness WebUI, deepseek-flash
model); every command, log and result quoted above was actually executed on
this machine and reviewed by me.

Eason
1836949523@xxxxxx