[PATCH v15 0/6] Merge redmi-wmi into bitland-mifs-wmi

[Mingyou Chen <qby140326@gmail.com>]

This patch series consolidates the standalone 'redmi-wmi' driver into the
'bitland-mifs-wmi' driver to eliminate code duplication and centralize
the maintenance of overlapping ACPI WMI event streams.

Bitland is the ODM manufacturer for various Xiaomi Redmibook models. Both
platforms share the exact same keyboard event stream WMI GUID
(46C93E13-EE9B-4262-8488-563BCA757FEF). While redmi-wmi previously parsed
the 4-byte payload as a bulk u32 scancode, bitland-mifs-wmi deconstructed
it into discrete type/id/value fields.

Redmi operations were not contained in this patch series, future reverse
engineering is required.

This series introduce a newly reported mic-mute hotkey definition
for Redmibooks, dropped the previous redmi-wmi driver and intrudoced
the quirks table for the bitland-mifs-wmi driver.

I don't have a Redmi or other Bitland device. So I cannot work on the
real device.

Features are working properly on my device (Lecoo Bellator N176).

I leave the future reverse engineering work to the community.

Tests are welcome.

And by the way, the no_set member in bitland_profile_entry means a
platform profile is only report by the firmware but not available for
set.

> And I've got a question, from sashiko's comment in my v12
> 
> https://sashiko.dev/#/patchset/20261012133648.132363-1-qby140326%40gmail.com
> 
> > Will this result in the loss of KEY_PERFORMANCE events on event-only legacy
> > devices?
> > Looking at bitland_mifs_wmi_probe() in drivers/platform/x86/bitland-mifs-wmi.c,
> > if dev_type == BITLAND_WMI_EVENT, it returns early after registering the input
> > device:
> > 	if (dev_type == BITLAND_WMI_EVENT) {
> > 		/* Register input device for hotkeys */
> > 		drv_data->input_dev = devm_input_allocate_device(&wdev->dev);
> > 		...
> > 		return input_register_device(drv_data->input_dev);
> > 	}
> > When the performance key is pressed, bitland_mifs_wmi_notify() intercepts it,
> > invokes the bitland_notifier_list, and returns without reporting an input event:
> > 	case WMI_EVENT_PERFORMANCE_PLAN:
> > 	case WMI_EVENT_PERFORMANCE_PLAN_ALT:
> > 		blocking_notifier_call_chain(&bitland_notifier_list,
> > 					     BITLAND_NOTIFY_PLATFORM_PROFILE,
> > 					     NULL);
> > 		return;
> > Because the platform profile and notifier were not registered during probe
> > for event-only devices, does this mean the events are silently dropped instead
> > of emitting KEY_PERFORMANCE like the old driver did?
> 
> I ackknowledged that KEY_PERFORMANCE (WMI_EVENT_PERFORMANCE_PLAN_ALT in
> bitland-mifs-wmi) looks like an event in this LKML thread
> 
> > Since the event reports a change that has already happened,
> > platform_profile_notify() is the natural way to pass it on, as
> > suggested in my v6 reply: power-profiles-daemon then re-reads the
> > profile, which is harmless after the driver's own writes too. If
> > KEY_PERFORMANCE should stay for on-screen displays (Ibragim asked to
> > keep these events observable), it may be worth not reporting it for the
> > event that echoes the driver's own write, or at least saying in a
> > comment that it reports a mode change that already happened. On
> > Ibragim's TM2209 the profile SET is reported not to work [3], so there
> > 0x16 can only come from Fn+K and the echo does not exist; Ibragim, can
> > you confirm?
> 
> https://lore.kernel.org/all/20261008152647.1510152-1-uselessfire@gmail.com/
> 
> So should I follow sashiko's advice?
> 
> And some remaining comments from sashiko's review of my v13:
> 
> > > -	/* Keyboard backlight: Off / Auto / Low / High (new state in byte 2) */
> > > -	{KE_KEY, 0x00000501,	{KEY_KBDILLUMTOGGLE}},
> > > -	{KE_KEY, 0x00800501,	{KEY_KBDILLUMTOGGLE}},
> > > -	{KE_KEY, 0x00050501,	{KEY_KBDILLUMTOGGLE}},
> > > -	{KE_KEY, 0x000a0501,	{KEY_KBDILLUMTOGGLE}},
> > > -
> > > -	/* Xiaomi G Command Center */
> > > -	{KE_KEY, 0x00010a01,	{KEY_VENDOR}},
> > > -
> > > -	/* OEM preset power mode: 1=Balanced 2=Silent 3=Turbo 4=Full speed */
> > > -	{KE_KEY, 0x00011601,	{KEY_PERFORMANCE}},
> > > -	{KE_KEY, 0x00021601,	{KEY_PERFORMANCE}},
> > > -	{KE_KEY, 0x00031601,	{KEY_PERFORMANCE}},
> > > -	{KE_KEY, 0x00041601,	{KEY_PERFORMANCE}},
> > In drivers/platform/x86/redmi-wmi.c, redmi_wmi_notify() reported these
> > keyboard backlight events (event_id 0x05) as KEY_KBDILLUMTOGGLE and OEM preset
> > power mode events (event_id 0x16) as KEY_PERFORMANCE through
> > sparse_keymap_report_entry().
> > In drivers/platform/x86/bitland-mifs-wmi.c, bitland_mifs_wmi_keymap defines
> > the four WMI_EVENT_KBD_BRIGHTNESS entries for KEY_KBDILLUMTOGGLE:
> > 	{ KE_KEY, BI_HOTKEY_CODE(WMI_EVENT_KBD_BRIGHTNESS, 0, 0), {KEY_KBDILLUMTOGGLE} },
> > 	{ KE_KEY, BI_HOTKEY_CODE(WMI_EVENT_KBD_BRIGHTNESS, 0x80, 0), {KEY_KBDILLUMTOGGLE} },
> > 	{ KE_KEY, BI_HOTKEY_CODE(WMI_EVENT_KBD_BRIGHTNESS, 5, 0), {KEY_KBDILLUMTOGGLE} },
> > 	{ KE_KEY, BI_HOTKEY_CODE(WMI_EVENT_KBD_BRIGHTNESS, 0x0a, 0), {KEY_KBDILLUMTOGGLE} },
> > However, bitland_mifs_wmi_notify() returns early for both
> > WMI_EVENT_KBD_BRIGHTNESS and WMI_EVENT_PERFORMANCE_PLAN_ALT before reaching
> > bitland_mifs_wmi_report_key():
> > 	switch (event->event_id) {
> > 	case WMI_EVENT_KBD_BRIGHTNESS:
> > 		brightness = event->value_low;
> > 		blocking_notifier_call_chain(&bitland_notifier_list,
> > 					     BITLAND_NOTIFY_KBD_BRIGHTNESS,
> > 					     &brightness);
> > 		return;
> > 	case WMI_EVENT_PERFORMANCE_PLAN:
> > 	case WMI_EVENT_PERFORMANCE_PLAN_ALT:
> > 		blocking_notifier_call_chain(&bitland_notifier_list,
> > 					     BITLAND_NOTIFY_PLATFORM_PROFILE,
> > 					     NULL);
> > 		return;
> > 	...
> > 	}
> > 	payload = get_unaligned_le32(buffer->data);
> > 	bitland_mifs_wmi_report_key(wdev, payload);
> > Does this early return leave the WMI_EVENT_KBD_BRIGHTNESS entries in
> > bitland_mifs_wmi_keymap unreachable and cause a regression on Redmibook
> > laptops (especially models that only expose BITLAND_EVENT_GUID without the
> > BITLAND_MIFS_GUID control device) when pressing the keyboard backlight or
> > power mode hotkeys?
> > [ ... ]
> 
> Don't actually agree with sashiko, if we report the key to the
> userspace, when WMs handle the KEY_KBDILLUMTOGGLE key, the keyboard
> light will be triggered twice if the firmware already respond to the event,
> which is not expected.
> 
> So the question is, does the firmware respond the KBD_BRIGHTNESS event?
> And should we report this key to userspace?

From Chris' comment:

> - Fn+Space (keyboard backlight) sends no WMI event at all, neither 0x05
>   nor anything else, and does not change the backlight under Linux. So
>   this model cannot tell whether the firmware handles KBD_BRIGHTNESS.
> 
> - Fn+K sends event 0x28 with value_low 0x01 on every press (01 28 01 00),
>   not 0x16. The firmware does not change the mode by itself: the
>   SystemPerMode value (EC 0x68) stays the same across the presses. If
>   0x28 is the performance mode key on this model, it is a request rather
>   than a notification, so platform_profile_cycle() would fit. 0x28 is
>   currently logged as "Unknown WMI event".
> 
> - On Windows on the same machine, with Xiaomi PC Manager not running
>   (it fails to start on this install), neither Fn+K nor Fn+Space does
>   anything either. So Fn+K looks like a request that Xiaomi's software
>   normally acts on, not a mode change made by the firmware.

I think different models have different behaviors on this.
Should we add a quirk item?

v15:
Fix the build issue reported by kernel-test-bot
https://lore.kernel.org/oe-kbuild-all/202610270608.l51GVbZ8-lkp@intel.com/

v14:
Drop the accept_zero_function quirk based on Chris' comment
https://lore.kernel.org/lkml/CAAcRvKPSk5FYzZGkw12cPVGkxWVGFACwRvupBDDNae7B_JwF0A@mail.gmail.com/

v13:
Fix the zero function value problem find on my device
Fix the memcpy size issue
Remove WMI_EVENT_PERFORMANCE_PLAN_ALT in the keymap
Select BITLAND_MIFS_WMI and deprecate REDMI_WMI instead remove the
config entry

v12:
Fix the issues mentioned in https://lore.kernel.org/all/20261008152647.1510152-1-uselessfire@gmail.com/ .
Copy payload_data to output->data at bitland_mifs_wmi_call, not
overwrite the entire struct.
Correct the key name (Mic Mute) in the commit message of
"platform/x86: bitland-mifs-wmi: Add Redmi mic-mute key entries"
and my device doesn't have a FN-ESC key, so I renamed the enum variant to
WMI_EVENT_MIC_MUTE.

v11:
Add missing return_code_at_end and accept_zero_function logic
Fallback to balanced platform profile if resume to performance failed

v10:
Replace the previous "profile table" with dmi quirk table

v9:
Add the missing feature introduced in the commit
e0d6312578e1 ("platform/x86: redmi-wmi: report EC state change events").

v8:
Correct Ilya Gladyshev's email address in the MAINTAINERS entry

v7:
Swap low bit and high bit for WMI_EVENT_KBD_BRIGHTNESS
in bitland_mifs_wmi_keymap
0x00800501 -> BI_HOTKEY_CODE(WMI_EVENT_KBD_BRIGHTNESS, 0x80, 0),

Report KEY_FN_ESC when WMI_EVENT_FNLOCK_STATE events received
Rename the reserved names
Use Xmas tree order in bitland_mifs_wmi_notify
Collect the Tested-by and Reviewed-by tags

v6:
Drop the wrong Redmi ops

v5:
Correct Xiaomi DMI vendor name

v4:
Map PLATFORM_PROFILE_PERFORMANCE to wmi performance mode if the device
doesn't support full-speed mode.


Mingyou Chen (6):
  MAINTAINERS: Add maintainer entry of bitland-mifs-wmi driver
  platform/x86: bitland-mifs-wmi: Merge the function of redmi-wmi into
    the bitland driver
  platform/x86: bitland-mifs-wmi: Add Redmi mic-mute key entries
  platform/x86: redmi-wmi: Drop redmi-wmi driver
  platform/x86: bitland-mifs-wmi: Add quirks table
  platform/x86: bitland-mifs-wmi: Fallback to balanced platform profile
    if last performance profile is not available

 MAINTAINERS                             |   7 +-
 drivers/platform/x86/Kconfig            |  13 +-
 drivers/platform/x86/Makefile           |   1 -
 drivers/platform/x86/bitland-mifs-wmi.c | 353 +++++++++++++++++-------
 drivers/platform/x86/redmi-wmi.c        | 154 -----------
 5 files changed, 256 insertions(+), 272 deletions(-)
 delete mode 100644 drivers/platform/x86/redmi-wmi.c


base-commit: 9d3475065167197742b0882aff21cf8e78393277
-- 
2.56.0