Re: [PATCH v6 5/5] platform/x86: bitland-mifs-wmi: Add per-machine ops table

[Anton Karasev]

Hi,

Data for the per-machine table from a Xiaomi Redmi Book Pro 16 2024
(DMI: sys_vendor "XIAOMI", board_name "TM2309"; BIOS RMAMT6B0P0B0B,
bios_release and ec_firmware_release 1.11), the same model as in
Martiya's report. RMAMT6B0P0B0B (August 2025) is the latest BIOS Xiaomi
publishes for this model, so this is what an entry would be written
against. Its values match neither the Bitland defaults nor the Redmi map
proposed in v5 6/6. The full acpidump is attached to bugzilla 222062:
https://bugzilla.kernel.org/attachment.cgi?id=310971
The WMI method is \_SB.PC00.WMID.WMAA in the SSDT with OEM Table ID
XMCC1806; QFAN and NTDP are in the DSDT.

Mode values
-----------

WMAA stores the value written with WMI_FN_SYSTEM_PER_MODE in the EC
register QFAN as is (5 and 7 go to a separate register, SMMD, instead),
and NTDP in the DSDT maps QFAN to the DPTF variable \_SB.ODV1 (odvp1 in
sysfs) that thermald --adaptive uses to pick the policy from the GDDV:

  QFAN   meaning                          ODV1
  0, 1   balanced (Fn+K sets 1)           0
  2      quiet                            2
  3      performance ("Turbo")            1
  4      full speed ("Geek")              4

GET returns QFAN for 1..4 and 0 otherwise (so 0 after a SET of 0).
Fn+K on this model cycles 1 -> 3 -> 2.

I tested this with a local build that maps low-power/balanced/
performance to 2/1/3: power-profiles-daemon power-saver, balanced and
performance give odvp1 2, 0 and 1, and thermald loads the matching GDDV
targets (PL1 limits, TCC offset), both on AC and on battery.

On the DMI match: the v5 6/6 match on sys_vendor "Redmi"/"TIMI" would
not cover this machine, and performance = 0 from that map is balanced
here. The REDMI Book Pro 16 2025 in Aleksey's report also has
sys_vendor "XIAOMI" but uses different values, so an entry for this
model has to match board_name "TM2309". The Pro 14 2024 (TM2307) is
built on the same platform (Xiaomi's downloads for both, the BIOS
included, are filed under one platform name, N56N57) and may behave the
same; I cannot verify that.

Capability checks
-----------------

a) Performance on AC and on battery. WMI_FN_SYSTEM_AC_TYPE is not
   implemented on this BIOS, so with Armin's "Treat
   WMI_FN_SYSTEM_AC_TYPE as optional" the capability check passes on
   AC. The write itself is still reported as failed here, though:
   WMAA's SET branches set only the return code and leave the function
   id at 0 (only the GET branches fill it in), so "Detect failed
   function calls" (23cc56f6dea6 in for-next) returns -ENOMSG for every
   SET on this BIOS, although the firmware applies it -- the same as
   Chris reported for the Book Pro 14. I checked it with the for-next
   version of the driver built for 7.2.7: every write of low-power,
   balanced and performance failed with -ENOMSG while QFAN changed to
   2, 0 and 3; with Chris's "Only check the function id of GET
   responses" on top, all of them succeed.
   On battery, power_supply_is_system_supplied() still refuses
   performance, although the firmware supports Turbo on DC: Fn+K
   reaches it on battery, the GDDV has a DC Turbo target, and writing 3
   on battery works (odvp1 1, thermald applies the DC Turbo limits).

b) Full speed. The firmware does not validate the mode at all. Writing
   4 was accepted and applied (odvp1 4, thermald loads the Geek targets;
   on AC the PL1 ramped towards the 90 W Geek maximum) both on battery
   and on a 100 W USB-C PD charger, while Fn+K never offers full speed
   in either case. It is not a charger thing either: with the stock
   140 W USB-C charger (the EC register ADPW then reads 140, and GET of
   command 0x10, subcommand 3, would report the adapter as not below
   140 W) Fn+K still cycles only 1 -> 3 -> 2. So on this model full
   speed is never offered by the vendor's own key, and whether it is
   exposed has to be decided by the driver; the firmware will not stop
   it.

Commands that are not implemented, and one that is dangerous
------------------------------------------------------------

On this BIOS WMAA implements only command 0x08 (GET and SET), 0x0a
subcommand 5, and 0x10 (GET subcommands 1-3, SET subcommand 2 only).
Other command IDs answer 0xE000, among them everything else the driver
uses: 0x09 (gpu_mode), 0x0d (fan speeds), 0x12 (keyboard brightness),
0x13 (AC type), 0x14 (fan_boost) and 0x16 (CPU temperature).
Unhandled subcommands of 0x0a and 0x10 mostly return status 0, and a
GET of 0x0a answers 0x8000 whatever the subcommand. The hwmon device,
the kbd_backlight LED, gpu_mode and fan_boost therefore have nothing
behind them on this machine; probing support at probe time would avoid
exposing them.

kb_mode is worse than unsupported. kb_mode_store() sends command 0x10
(WMI_FN_RGB_KB_MODE) with the mode in the first payload byte. On this
firmware command 0x10 is the battery interface, and subcommand 2 is the
charge protection (bit 0 of the EC register LONL, 80 % limit; reportedly
what Xiaomi's Windows tools toggle): WMAA sets the bit only for the
value 1 and clears it for anything else. "echo fixed > kb_mode" is
therefore 0x10/2 with value 0. I verified on this machine that it
silently turns off charge protection -- LONL goes from 0x31 to 0x00, the
charge limit in the EC goes from 80 back to 100 and the battery, which
had been held at 80 %, starts charging again -- while the firmware
reports success (0x8000). That was on 7.2.7, whose driver does not check
the reply; with 23cc56f6dea6 the write returns -ENOMSG instead, but
protection is off all the same. I think kb_mode must not be exposed on
these machines.

Once the generic profile table has settled I can send a patch with the
entry for this model and the kb_mode fix on top of it, and I am happy to
test patches in the meantime.

Thanks,
Anton Karasev