Re: [RFC] platform/x86: redmi-wmi/bitland-mifs-wmi: shared WMI GUID ownership

[Armin Wolf <W_Armin@gmx.de>]

Am 24.06.26 um 01:48 schrieb Nika Krasnova:

> Hello,
>
> I am adding support for a mic-mute LED to redmi-wmi (a follow-up to the
> keymap patch [1]) and ran into a GUID ownership problem with
> bitland-mifs-wmi.
>
> bitland-mifs-wmi claims two WMI GUIDs in its id_table:
>
>    46C93E13-EE9B-4262-8488-563BCA757FEF  (event device)
>    B60BFB48-3E5B-49E4-A0E9-8CFFE1B3434B  (control device)
>
> redmi-wmi already claims the event GUID for its keymap, so the two
> overlap there today, with nothing deciding which one wins. The mic-mute
> LED needs the control device -- the EC mic-mute field sits behind its
> WMAA method -- and bitland-mifs-wmi claims that one too, so my patch
> would extend the overlap to the control GUID as well.
>
> Both drivers set MODULE_DEVICE_TABLE(wmi, ...), so udev autoloads both
> and the device goes to whichever probes first.
>
> The outcome is load-order dependent. Loading bitland-mifs-wmi first, it
> binds *both* devices, and a redmi-wmi loaded afterwards binds nothing:
>
>    $ for d in /sys/bus/wmi/devices/*; do \
>        printf '%s -> %s\n' "$(basename "$d")" \
>          "$(basename "$(readlink "$d/driver")")"; done | column -t
>    ...
>    46C93E13-EE9B-4262-8488-563BCA757FEF-0   ->  bitland-mifs-wmi
>    B60BFB48-3E5B-49E4-A0E9-8CFFE1B3434B-4   ->  bitland-mifs-wmi
>
> In this order redmi-wmi is shut out entirely, including the mic-mute key
> (bitland's keymap has none).
>
> This is a RedmiBook Pro 16 2024 (DMI_SYS_VENDOR "XIAOMI", board TM2309).
> These machines appear to share a common ODM firmware base with
> Bitland's: the same WMI GUIDs are exposed under a different DMI vendor.
> Neither driver inspects DMI, so neither can tell whose machine it is on.
>
> Two complications:
>
> - The control device (B60BFB48) is one multiplexed method (WMAA):
>    mic-mute, keyboard backlight, platform profile and fan all sit behind
>    it as sub-functions. Its features cannot be split between drivers; one
>    driver has to handle all of them.
>
> - The mic-mute LED needs one driver to own *both* devices. The EC
>    reflects an LED write as the very same WMI event as a physical
>    mic-mute key press, so suppressing the self-induced event requires the
>    LED-writing path and the key-event path to share state. A split
>    (control in one driver, event in the other) cannot coordinate it.
>
> So per machine one driver needs to own both devices and provide all the
> features that machine needs. The options I see:
>
>   1. The two are merged into one driver for this ODM platform that owns
>      both GUIDs and DMI-gates the per-brand pieces (keymap, mic-mute
>      LED).
>
>   2. bitland-mifs-wmi gains the Redmi mic-mute key + LED (DMI-gated to
>      XIAOMI), since it already owns both devices and provides the other
>      features here; redmi-wmi would then not bind on these machines.
>
>   3. redmi-wmi becomes the Redmi owner: it absorbs the control-device
>      features (backlight/profile/fan) plus the mic-mute LED, and
>      bitland-mifs-wmi DMI-gates itself out of Redmi hardware.
>
> In cases 2 and 3 the split is enforced by a DMI check in probe,
> returning -ENODEV on a vendor mismatch, so the declining driver yields
> the device to some'ne else. Both sides must gate from the start: once
> the wrong driver binds, the device is -EBUSY for the other and is not
> re-offered.
>
> Mingyou Chen (bitland-mifs-wmi author, CC'd) told me off-list that this
> is a GUID overlap, that his Bitland hardware has no mic-mute key, and
> that he is fine with the mic-mute support living in redmi-wmi.
>
> The mic-mute LED is already implemented and tested on my RedmiBook Pro
> 16. I can send it, and the bitland-mifs-wmi changes, as a proper series
> once we settle on a shape.
>
> This follows up the mic-mute keymap patch [1] and an earlier question
> about the overlap [2].

I think that Bitland also manufactures hardware for Xiaomi, so both drivers
seem to actually control the same hardware.

Because of this i would go with option 1 (merging both drivers into one).

Thanks,
Armin Wolf

>
> [1]: https://lore.kernel.org/all/20260620145928.2156909-1-nika@nikableh.moe/
> [2]: https://lore.kernel.org/all/20260531123345.237521-1-nika@nikableh.moe/
>