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

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

[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].

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

-- 
Nika Krasnova

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

[Armin Wolf]

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/
>

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

[Mingyou Chen]

On 7/1/26 5:07 AM, Armin Wolf wrote:
> 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/
>>
Hello, the redmi device is using 32bits (4 bytes) to represent an event, 
but my bitland device uses 16bits (2 bytes)

This is the structure to represent an event

struct bitland_mifs_event {
     u8 event_type;
     u8 event_id;
     u8 value_low;    /* For most events, this is the value */
     u8 value_high;    /* For fan speed events, combined with value_low */
     u8 reserved[4];
} __packed;

The raw events are hard-encoded (Little-Endian) in the redmi driver (in 
the redmi_wmi_keymap constant)

The Redmi device uses value_low in its hotkey event payload

Using magic numbers in the kernel code is bad

So should I add an macro to construct the event code like

#define WMI_SCANCODE(type, id, low, high) (((u32)(high) << 24) | 
((u32)(low) << 16) | ((u32)(id) << 8) | (u32)(type))