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

[Mingyou Chen <qby140326@gmail.com>]

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