Re: [RFC PATCH 0/3] platform: lenovo: architecture independent home for the Lenovo WMI drivers

["Mark Pearson" <mpearson-lenovo@squebb.ca>]

On Sun, Nov 15, 2026, at 3:12 PM, Hans de Goede wrote:
> p.s.
>
> On 15-Nov-26 21:10, Hans de Goede wrote:
>> On 15-Nov-26 16:33, Hans de Goede wrote:
>> 
>> <snip>
>> 
>>>>   b. Should the Fn key event handling stay a separate small driver, or
>>>>      be factored out of ideapad-laptop so x86 and arm64 share one path?
>>>>      ideapad-laptop handles the event only when its VPC platform driver
>>>>      is bound, and the arm64 machines expose none of the VPC interface
>>>>      it is built on (no _CFG, VPCR/VPCW, DYTC or HALS/SALS), so making
>>>>      it the single driver means gating most of its probe. Two smaller
>>>>      options: lift ideapad-laptop's own Fn key wmi_driver and keymap
>>>>      into this file and let ideapad-laptop register for the events it
>>>>      still wants (Fn lock LED, DYTC cycle), or the hid-asus/asus-wmi
>>>>      shape where a companion WMI module exports the event to a
>>>>      subsystem driver. The keymap in patch 2 duplicates entries of
>>>>      ideapad-laptop's table on purpose until that is decided.
>>>
>>> IIRC the ideapad-laptop driver is a bit of a mess atm, so factoring
>>> a common handling for the the Fn key events out of this and sharing
>>> that sounds like a nice cleanup.
>>>
>>> I see that patch 2/3 uses the new wmi-driver/-bus infra which is
>>> nice and clean.
>>>
>>> So maybe just keep your existing stand-alone driver for both x86_64 +
>>> arm64 and drop the WMI event handling from ideapad-laptop.
>>>
>>> I guess this may hit some problems where WMI event handlig is used
>>> in ideapad-laptops integrating with some VPC functionality.
>>>
>>> For that purpose I think that the new
>>> drivers/platform/lenovo/wmi-hotkeys.c could maybe expose some
>>> notifier and call that for events it does not handle itself
>>> and then ideapad-laptop can depend on some function to register
>>> a listener on that notifier (1) and register a notifier handler
>>> staying out of WMI handling itself.
>>>
>>> No idea if this is feasible / how clean the end result will be,
>>> just brainstorming and saying yes to doing some refactoring of
>>> the somewhat messy ideapad-laptop code.
>>>
>>> Note that https://github.com/systemd/systemd/blob/main/hwdb.d/60-keyboard.hwdb
>>> has some mappings for "Ideapad extra buttons" input devices
>>> (+ DMI match), so if any of the buttons remapped there end up
>>> under the new WMI driver then that should probably give its
>>> input device the same name, to make sure those mappings still
>>> apply.
>> 
>> Also see this just posted ideapad-laptop series which does
>> something similar for handling YMC events:
>> 
>> https://lore.kernel.org/platform-driver-x86/20261116-ymc-82yl-v1-0-fac1a2b01a84@rong.moe/
>
> I see that this routes everything through a new lenovo wmi-events
> helper which uses a single notifier to which interested parties
> like ideapad-laptop can subscribe. I think this models could
> be extended to also handle the hotkeys, assuming all the base
> bits are moved into the new drivers/platform/lenovo/ dir.
>
This all sounds good to me. I would quite like to break thinkpad_apci up a bit ultimately too....just tough finding the time.

The think-lmi driver should likely move here (and a newer version tlmi-* that I should be posting for review next week, fingers crossed).

Mark