Re: [PATCH v11] platform/x86: bitland-mifs-wmi: Add new Bitland MIFS WMI driver

Hi,

Thanks for the work on this driver. I'm testing it on a laptop that isn't
in your reverse-engineering set, and wanted to report that fan control
seems to be a no-op here even though everything else (sensors, gpu_mode,
platform-profile read, kb backlight) looks fine.

Hardware:
- Model: Xiaomi Redmi Book Pro 14 2024, board TM2307
- BIOS: V24C1, dated 06/10/2025
- CPU: Intel Core Ultra 5 125H
- Kernel: 7.1.8-1-cachyos (Arch/CachyOS)

Problem:
Fans (CPU/GPU/SYS, as reported by the bitland_mifs hwmon block) never spin
under Linux, even at CPU package temps of 62-63C (coretemp). Confirmed via
dual-boot that the fans work correctly under Windows, so this isn't a
hardware fault.

What I tried:

1. `fan_boost` sysfs attribute (WMI cmd 0x14, MaxFanSpeedSwitch):
     echo 1 | sudo tee .../B60BFB48-3E5B-49E4-A0E9-8CFFE1B3434B-4/fan_boost
   - Write succeeds with no error.
   - fan1/2/3_input under hwmon (bitland_mifs) stay at 0 RPM.
   - No audible/physical change.

2. Enabled dynamic debug on the module to trace notify events:
     echo 'module bitland_mifs_wmi +p' | sudo tee
/sys/kernel/debug/dynamic_debug/control
   - Confirmed pr_debug call sites are active (bitland_mifs_wmi_notify,
     bitland_mifs_wmi_resume).
   - Retried the fan_boost write with tracing on: no notify/state-change/
     WMI event lines appear in dmesg at all in response to the write.

3. Tried the standard mainline ACPI fan interface instead (bypassing this
   driver entirely). 5x PNP0C0B cooling devices are present
   (cooling_device0-4, type=Fan, max_state=1):
     for i in 0 1 2 3 4; do echo 1 | sudo tee
/sys/class/thermal/cooling_device$i/cur_state; done
   - All 5 confirmed set to cur_state=1 on readback.
   - Still zero RPM change, no audible response.

4. Noted a mismatch: the acpitz thermal zone that ACPI trip points are
   bound to reads ~27C (presumably a chassis/skin sensor) while coretemp
   reads 60C+, so even automatic/EC-driven fan curves triggered via that
   zone would never fire under Linux regardless of the WMI driver.

Conclusion so far:
Both the new fan_boost control and the standard ACPI PNP0C0B cur_state
override are complete no-ops on this specific model/firmware, with zero EC
acknowledgment visible even with driver tracing on. Since Windows drives
the fans fine, the EC likely requires some additional init/handshake/
enable step (that the Windows vendor driver performs) which neither Linux
path is triggering. Given the driver's docs mention it was reverse-
engineered primarily against Lenovo-rebadged Bitland units, I suspect this
Xiaomi/Redmi variant has a different EC command mapping or requires an
additional enable call not yet implemented.

WMI GUIDs present on this machine, for reference:
- B60BFB48-3E5B-49E4-A0E9-8CFFE1B3434B (control methods, hosts
fan_boost/gpu_mode/platform-profile/kb_mode/hwmon)
- 46C93E13-EE9B-4262-8488-563BCA757FEF (event notifications)
- 3F9E3C26-B077-4F86-91F5-37FF64D8C7ED
- 1DCEAF0A-4D63-44BB-BD0C-0D6281BFDDC5
- FA78E245-2C0F-4CA1-91CF-15F34E474850
- 05901221-D566-11D1-B2F0-00A0C9062910 (multiple instances, standard BMOF)
- A6FEA33E-DABF-46F5-BFC8-460D961BEC9F
- F80A5498-23F3-4053-A244-B39067EC476F
- 1F13AB7F-6220-4210-8F8E-8BB5E71EE969
- 2BC49DEF-7B15-4F05-8BB7-EE37B9547C0B
- 657B6048-310C-4A90-A211-10A17922A0AF

Happy to test patches, dump ACPI tables (DSDT/SSDT), pull the Windows
driver's WMI call sequence via API Monitor, or gather any other debug
info that would help. This looks like a useful data point for broadening
hardware support on this model, so just let me know what's most useful to
collect next.

Thanks,
Milos