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

[Armin Wolf <W_Armin@gmx.de>]

Am 15.08.26 um 09:15 schrieb Miloš Vlku:

> 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

Sorry for the late reply. Could you please share the output of "acpidump"?

Thanks,
Armin Wolf