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

[Nika Krasnova <nika@nikableh.moe>]

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