[PATCH] platform/x86: lenovo-hotkey: Handle missing hardware features gracefully

[PATCH] platform/x86: lenovo-hotkey: Handle missing hardware features gracefully

[Armin Wolf]

Not all devices support audio mute and microphone mute LEDs, so the
explicitly checks for hardware support while probing. However missing
hardware features are treated as errors, causing the driver so fail
probing on devices that do not support both LEDs.

Fix this by simply ignoring hardware features that are not present.
This way the driver will properly load on devices not supporting both
LEDs and will stop throwing error messages on devices with no LEDS
at all.

Reported-by: Andrei Tescula <atescula@gmail.com>
Closes: https://https://lore.kernel.org/platform-driver-x86/2eda8f9b-9421-4068-87ae-ccfd834649bc@gmail.com/
Reported-by: BEST8OY <alireza.bestboyy@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220271
Tested-by: BEST8OY <alireza.bestboyy@gmail.com>
Fixes: 61250669eaa9 ("platform/x86:lenovo-wmi-hotkey-utilities.c: Support for mic and audio mute LEDs")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
---
 .../platform/x86/lenovo/wmi-hotkey-utilities.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/lenovo/wmi-hotkey-utilities.c b/drivers/platform/x86/lenovo/wmi-hotkey-utilities.c
index 89153afd7015..44f489336199 100644
--- a/drivers/platform/x86/lenovo/wmi-hotkey-utilities.c
+++ b/drivers/platform/x86/lenovo/wmi-hotkey-utilities.c
@@ -127,21 +127,26 @@ static int lenovo_super_hotkey_wmi_led_init(enum mute_led_type led_type, struct
 	else
 		return -EIO;
 
-	wpriv->cdev[led_type].max_brightness = LED_ON;
-	wpriv->cdev[led_type].flags = LED_CORE_SUSPENDRESUME;
-
 	switch (led_type) {
 	case MIC_MUTE:
+		/*
+		 * A missing hardware feature is not an error, so do not return
+		 * an error here.
+		 */
 		if (led_version != WMI_LUD_SUPPORT_MICMUTE_LED_VER)
-			return -EIO;
+			return 0;
 
 		wpriv->cdev[led_type].name = "platform::micmute";
 		wpriv->cdev[led_type].brightness_set_blocking = &lsh_wmi_micmute_led_set;
 		wpriv->cdev[led_type].default_trigger = "audio-micmute";
 		break;
 	case AUDIO_MUTE:
+		/*
+		 * A missing hardware feature is not an error, so do not return
+		 * an error here.
+		 */
 		if (led_version != WMI_LUD_SUPPORT_AUDIOMUTE_LED_VER)
-			return -EIO;
+			return 0;
 
 		wpriv->cdev[led_type].name = "platform::mute";
 		wpriv->cdev[led_type].brightness_set_blocking = &lsh_wmi_audiomute_led_set;
@@ -152,6 +157,9 @@ static int lenovo_super_hotkey_wmi_led_init(enum mute_led_type led_type, struct
 		return -EINVAL;
 	}
 
+	wpriv->cdev[led_type].max_brightness = LED_ON;
+	wpriv->cdev[led_type].flags = LED_CORE_SUSPENDRESUME;
+
 	err = devm_led_classdev_register(dev, &wpriv->cdev[led_type]);
 	if (err < 0) {
 		dev_err(dev, "Could not register mute LED %d : %d\n", led_type, err);
-- 
2.39.5

Re: [PATCH] platform/x86: lenovo-hotkey: Handle missing hardware features gracefully

[Kurt Borja]

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

Hi Armin,

On Fri Jun 27, 2025 at 4:54 PM -03, Armin Wolf wrote:
> Not all devices support audio mute and microphone mute LEDs, so the
> explicitly checks for hardware support while probing. However missing
> hardware features are treated as errors, causing the driver so fail
> probing on devices that do not support both LEDs.
>
> Fix this by simply ignoring hardware features that are not present.
> This way the driver will properly load on devices not supporting both
> LEDs and will stop throwing error messages on devices with no LEDS
> at all.

This patch makes me wonder what is the policy around issues like this.
In fact I've submitted and changes that do the exact opposite :p
Like commit: 4630b99d2e93 ("platform/x86: dell-pc: Propagate errors when
detecting feature support")

IMO missing features should be treated as errors. i.e. The probe should
fail.

Quoting documentation [1]:

	If a match is found, the device’s driver field is set to the
	driver and the driver’s probe callback is called. This gives the
	driver a chance to verify that it really does support the
	hardware, and that it’s in a working state.

And again [2]:

	This callback holds the driver-specific logic to bind the driver
	to a given device. That includes verifying that the device is
	present, that it’s a version the driver can handle, that driver
	data structures can be allocated and initialized, and that any
	hardware can be initialized.

Both of these makes me wonder if such a "fail" or error message should
be fixed in the first place. In this case the probe correctly checks for
device support and fails if it's not found, which is suggested to be the
correct behavior.

BTW this also leaks `wpriv`, which would remain allocated for no reason.


[1] https://docs.kernel.org/driver-api/driver-model/binding.html
[2] https://docs.kernel.org/driver-api/driver-model/driver.html

-- 
 ~ Kurt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] platform/x86: lenovo-hotkey: Handle missing hardware features gracefully

[Armin Wolf]

Am 27.06.25 um 22:38 schrieb Kurt Borja:

> Hi Armin,
>
> On Fri Jun 27, 2025 at 4:54 PM -03, Armin Wolf wrote:
>> Not all devices support audio mute and microphone mute LEDs, so the
>> explicitly checks for hardware support while probing. However missing
>> hardware features are treated as errors, causing the driver so fail
>> probing on devices that do not support both LEDs.
>>
>> Fix this by simply ignoring hardware features that are not present.
>> This way the driver will properly load on devices not supporting both
>> LEDs and will stop throwing error messages on devices with no LEDS
>> at all.
> This patch makes me wonder what is the policy around issues like this.
> In fact I've submitted and changes that do the exact opposite :p
> Like commit: 4630b99d2e93 ("platform/x86: dell-pc: Propagate errors when
> detecting feature support")
>
> IMO missing features should be treated as errors. i.e. The probe should
> fail.

IMHO the probe should only fail if some features are deemed essential, like
required ACPI methods. Optional features like in this case LEDs should be
handled by the driver in a graceful manner if possible.

>
> Quoting documentation [1]:
>
> 	If a match is found, the device’s driver field is set to the
> 	driver and the driver’s probe callback is called. This gives the
> 	driver a chance to verify that it really does support the
> 	hardware, and that it’s in a working state.
>
> And again [2]:
>
> 	This callback holds the driver-specific logic to bind the driver
> 	to a given device. That includes verifying that the device is
> 	present, that it’s a version the driver can handle, that driver
> 	data structures can be allocated and initialized, and that any
> 	hardware can be initialized.
>
> Both of these makes me wonder if such a "fail" or error message should
> be fixed in the first place. In this case the probe correctly checks for
> device support and fails if it's not found, which is suggested to be the
> correct behavior.

The driver should only fail probing if it cannot handle some missing features.
In this case however both features (audio mute LED and mic mute LED) are completely
optional and the driver should not fail to load just because one of them is absent.

Just think about machines supporting only a single LED (audio or mic mute). Currently
the driver would fail to load on such devices leaving the users with nothing.

>
> BTW this also leaks `wpriv`, which would remain allocated for no reason.

wpriv will be freed using devres, so no memory leak here. However i admit that there is
some room for optimizations, however i leave this to the maintainer of the driver in
question.

Thanks,
Armin Wolf

>
>
> [1] https://docs.kernel.org/driver-api/driver-model/binding.html
> [2] https://docs.kernel.org/driver-api/driver-model/driver.html
>

Re: [PATCH] platform/x86: lenovo-hotkey: Handle missing hardware features gracefully

[Kurt Borja]

[-- Attachment #1: Type: text/plain, Size: 3574 bytes --]

On Fri Jun 27, 2025 at 6:17 PM -03, Armin Wolf wrote:
> Am 27.06.25 um 22:38 schrieb Kurt Borja:
>
>> Hi Armin,
>>
>> On Fri Jun 27, 2025 at 4:54 PM -03, Armin Wolf wrote:
>>> Not all devices support audio mute and microphone mute LEDs, so the
>>> explicitly checks for hardware support while probing. However missing
>>> hardware features are treated as errors, causing the driver so fail
>>> probing on devices that do not support both LEDs.
>>>
>>> Fix this by simply ignoring hardware features that are not present.
>>> This way the driver will properly load on devices not supporting both
>>> LEDs and will stop throwing error messages on devices with no LEDS
>>> at all.
>> This patch makes me wonder what is the policy around issues like this.
>> In fact I've submitted and changes that do the exact opposite :p
>> Like commit: 4630b99d2e93 ("platform/x86: dell-pc: Propagate errors when
>> detecting feature support")
>>
>> IMO missing features should be treated as errors. i.e. The probe should
>> fail.
>
> IMHO the probe should only fail if some features are deemed essential, like
> required ACPI methods. Optional features like in this case LEDs should be
> handled by the driver in a graceful manner if possible.
>
>>
>> Quoting documentation [1]:
>>
>> 	If a match is found, the device’s driver field is set to the
>> 	driver and the driver’s probe callback is called. This gives the
>> 	driver a chance to verify that it really does support the
>> 	hardware, and that it’s in a working state.
>>
>> And again [2]:
>>
>> 	This callback holds the driver-specific logic to bind the driver
>> 	to a given device. That includes verifying that the device is
>> 	present, that it’s a version the driver can handle, that driver
>> 	data structures can be allocated and initialized, and that any
>> 	hardware can be initialized.
>>
>> Both of these makes me wonder if such a "fail" or error message should
>> be fixed in the first place. In this case the probe correctly checks for
>> device support and fails if it's not found, which is suggested to be the
>> correct behavior.
>
> The driver should only fail probing if it cannot handle some missing features.
> In this case however both features (audio mute LED and mic mute LED) are completely
> optional and the driver should not fail to load just because one of them is absent.

I agree, both are individually optional, but at least one should be
required.

>
> Just think about machines supporting only a single LED (audio or mic mute). Currently
> the driver would fail to load on such devices leaving the users with nothing.

That's very true.

But I do still think if both fail the probe should still fail. Maybe
there is a way to accomplish this?

I'm thinking of something like

if (lenovo_super_hotkey_wmi_led_init(MIC_MUTE, dev) ||
    lenovo_super_hotkey_wmi_led_init(AUDIO_MUTE, dev))
    return -ENODEV;

What do you think?

>
>>
>> BTW this also leaks `wpriv`, which would remain allocated for no reason.
>
> wpriv will be freed using devres, so no memory leak here. However i admit that there is
> some room for optimizations, however i leave this to the maintainer of the driver in
> question.

Leak was a bit of an overstatement :) But if both features are missing
it would be kinda leaked, in practice.

>
> Thanks,
> Armin Wolf
>
>>
>>
>> [1] https://docs.kernel.org/driver-api/driver-model/binding.html
>> [2] https://docs.kernel.org/driver-api/driver-model/driver.html
>>


-- 
 ~ Kurt


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] platform/x86: lenovo-hotkey: Handle missing hardware features gracefully

[Armin Wolf]

Am 27.06.25 um 23:29 schrieb Kurt Borja:

> On Fri Jun 27, 2025 at 6:17 PM -03, Armin Wolf wrote:
>> Am 27.06.25 um 22:38 schrieb Kurt Borja:
>>
>>> Hi Armin,
>>>
>>> On Fri Jun 27, 2025 at 4:54 PM -03, Armin Wolf wrote:
>>>> Not all devices support audio mute and microphone mute LEDs, so the
>>>> explicitly checks for hardware support while probing. However missing
>>>> hardware features are treated as errors, causing the driver so fail
>>>> probing on devices that do not support both LEDs.
>>>>
>>>> Fix this by simply ignoring hardware features that are not present.
>>>> This way the driver will properly load on devices not supporting both
>>>> LEDs and will stop throwing error messages on devices with no LEDS
>>>> at all.
>>> This patch makes me wonder what is the policy around issues like this.
>>> In fact I've submitted and changes that do the exact opposite :p
>>> Like commit: 4630b99d2e93 ("platform/x86: dell-pc: Propagate errors when
>>> detecting feature support")
>>>
>>> IMO missing features should be treated as errors. i.e. The probe should
>>> fail.
>> IMHO the probe should only fail if some features are deemed essential, like
>> required ACPI methods. Optional features like in this case LEDs should be
>> handled by the driver in a graceful manner if possible.
>>
>>> Quoting documentation [1]:
>>>
>>> 	If a match is found, the device’s driver field is set to the
>>> 	driver and the driver’s probe callback is called. This gives the
>>> 	driver a chance to verify that it really does support the
>>> 	hardware, and that it’s in a working state.
>>>
>>> And again [2]:
>>>
>>> 	This callback holds the driver-specific logic to bind the driver
>>> 	to a given device. That includes verifying that the device is
>>> 	present, that it’s a version the driver can handle, that driver
>>> 	data structures can be allocated and initialized, and that any
>>> 	hardware can be initialized.
>>>
>>> Both of these makes me wonder if such a "fail" or error message should
>>> be fixed in the first place. In this case the probe correctly checks for
>>> device support and fails if it's not found, which is suggested to be the
>>> correct behavior.
>> The driver should only fail probing if it cannot handle some missing features.
>> In this case however both features (audio mute LED and mic mute LED) are completely
>> optional and the driver should not fail to load just because one of them is absent.
> I agree, both are individually optional, but at least one should be
> required.
>
>> Just think about machines supporting only a single LED (audio or mic mute). Currently
>> the driver would fail to load on such devices leaving the users with nothing.
> That's very true.
>
> But I do still think if both fail the probe should still fail. Maybe
> there is a way to accomplish this?
>
> I'm thinking of something like
>
> if (lenovo_super_hotkey_wmi_led_init(MIC_MUTE, dev) ||
>      lenovo_super_hotkey_wmi_led_init(AUDIO_MUTE, dev))
>      return -ENODEV;
>
> What do you think?

Normally i would agree to such a thing, but in this case the underlying WMI device
supports many more functions that are currently not supported by this driver. Additionally
the driver cannot control when the WMI device is registered, so it has to be prepared to
encounter a device without the features it supports.

Also keep in mind that a failing probe attempt produces a irritating error message.

>>> BTW this also leaks `wpriv`, which would remain allocated for no reason.
>> wpriv will be freed using devres, so no memory leak here. However i admit that there is
>> some room for optimizations, however i leave this to the maintainer of the driver in
>> question.
> Leak was a bit of an overstatement :) But if both features are missing
> it would be kinda leaked, in practice.

I see, however i would leave this to the maintainer of the driver because i have no hardware
to test the resulting patches :/.

Thanks,
Armin Wolf

>> Thanks,
>> Armin Wolf
>>
>>>
>>> [1] https://docs.kernel.org/driver-api/driver-model/binding.html
>>> [2] https://docs.kernel.org/driver-api/driver-model/driver.html
>>>
>

Re: [PATCH] platform/x86: lenovo-hotkey: Handle missing hardware features gracefully

[Mark Pearson]

Hi Armin & Kurt,

On Sat, Jun 28, 2025, at 8:01 AM, Armin Wolf wrote:
> Am 27.06.25 um 23:29 schrieb Kurt Borja:
>
>> On Fri Jun 27, 2025 at 6:17 PM -03, Armin Wolf wrote:
>>> Am 27.06.25 um 22:38 schrieb Kurt Borja:
>>>
>>>> Hi Armin,
>>>>
>>>> On Fri Jun 27, 2025 at 4:54 PM -03, Armin Wolf wrote:
>>>>> Not all devices support audio mute and microphone mute LEDs, so the
>>>>> explicitly checks for hardware support while probing. However missing
>>>>> hardware features are treated as errors, causing the driver so fail
>>>>> probing on devices that do not support both LEDs.
>>>>>
>>>>> Fix this by simply ignoring hardware features that are not present.
>>>>> This way the driver will properly load on devices not supporting both
>>>>> LEDs and will stop throwing error messages on devices with no LEDS
>>>>> at all.
>>>> This patch makes me wonder what is the policy around issues like this.
>>>> In fact I've submitted and changes that do the exact opposite :p
>>>> Like commit: 4630b99d2e93 ("platform/x86: dell-pc: Propagate errors when
>>>> detecting feature support")
>>>>
>>>> IMO missing features should be treated as errors. i.e. The probe should
>>>> fail.
>>> IMHO the probe should only fail if some features are deemed essential, like
>>> required ACPI methods. Optional features like in this case LEDs should be
>>> handled by the driver in a graceful manner if possible.
>>>
>>>> Quoting documentation [1]:
>>>>
>>>> 	If a match is found, the device’s driver field is set to the
>>>> 	driver and the driver’s probe callback is called. This gives the
>>>> 	driver a chance to verify that it really does support the
>>>> 	hardware, and that it’s in a working state.
>>>>
>>>> And again [2]:
>>>>
>>>> 	This callback holds the driver-specific logic to bind the driver
>>>> 	to a given device. That includes verifying that the device is
>>>> 	present, that it’s a version the driver can handle, that driver
>>>> 	data structures can be allocated and initialized, and that any
>>>> 	hardware can be initialized.
>>>>
>>>> Both of these makes me wonder if such a "fail" or error message should
>>>> be fixed in the first place. In this case the probe correctly checks for
>>>> device support and fails if it's not found, which is suggested to be the
>>>> correct behavior.
>>> The driver should only fail probing if it cannot handle some missing features.
>>> In this case however both features (audio mute LED and mic mute LED) are completely
>>> optional and the driver should not fail to load just because one of them is absent.
>> I agree, both are individually optional, but at least one should be
>> required.
>>
>>> Just think about machines supporting only a single LED (audio or mic mute). Currently
>>> the driver would fail to load on such devices leaving the users with nothing.
>> That's very true.
>>
>> But I do still think if both fail the probe should still fail. Maybe
>> there is a way to accomplish this?
>>
>> I'm thinking of something like
>>
>> if (lenovo_super_hotkey_wmi_led_init(MIC_MUTE, dev) ||
>>      lenovo_super_hotkey_wmi_led_init(AUDIO_MUTE, dev))
>>      return -ENODEV;
>>
>> What do you think?
>
> Normally i would agree to such a thing, but in this case the underlying 
> WMI device
> supports many more functions that are currently not supported by this 
> driver. Additionally
> the driver cannot control when the WMI device is registered, so it has 
> to be prepared to
> encounter a device without the features it supports.
>
> Also keep in mind that a failing probe attempt produces a irritating 
> error message.
>
>>>> BTW this also leaks `wpriv`, which would remain allocated for no reason.
>>> wpriv will be freed using devres, so no memory leak here. However i admit that there is
>>> some room for optimizations, however i leave this to the maintainer of the driver in
>>> question.
>> Leak was a bit of an overstatement :) But if both features are missing
>> it would be kinda leaked, in practice.
>
> I see, however i would leave this to the maintainer of the driver 
> because i have no hardware
> to test the resulting patches :/.
>

As a note, I'm on vacation for three weeks and avoiding accessing work emails, so won't be able to discuss this with Jackie properly until I'm back.

For history/context - this particular driver was a bit of a oddity as the Ideapads aren't in the Lenovo Linux program (hope they will be one day). We had a Thinkbook that is using the same LUDS interface, that we were Linux certifying, and LED support is a requirement to work.

I do think this needs revisiting a bit. I am leaning to agreeing that it shouldn't error out - but we were also being careful to not have this cause problems on HW we ourselves don't have access to. It would be nice if it could be extended to more platforms though.

I don't have the specs handy right now (would need to go on the Lenovo VPN for that). Is it OK if we re-visit this when I'm back at home and working?
Jackie - please do have a look and think about this in the meantime.

Mark

Re: [PATCH] platform/x86: lenovo-hotkey: Handle missing hardware features gracefully

[Armin Wolf]

Am 29.06.25 um 22:36 schrieb Mark Pearson:

> Hi Armin & Kurt,
>
> On Sat, Jun 28, 2025, at 8:01 AM, Armin Wolf wrote:
>> Am 27.06.25 um 23:29 schrieb Kurt Borja:
>>
>>> On Fri Jun 27, 2025 at 6:17 PM -03, Armin Wolf wrote:
>>>> Am 27.06.25 um 22:38 schrieb Kurt Borja:
>>>>
>>>>> Hi Armin,
>>>>>
>>>>> On Fri Jun 27, 2025 at 4:54 PM -03, Armin Wolf wrote:
>>>>>> Not all devices support audio mute and microphone mute LEDs, so the
>>>>>> explicitly checks for hardware support while probing. However missing
>>>>>> hardware features are treated as errors, causing the driver so fail
>>>>>> probing on devices that do not support both LEDs.
>>>>>>
>>>>>> Fix this by simply ignoring hardware features that are not present.
>>>>>> This way the driver will properly load on devices not supporting both
>>>>>> LEDs and will stop throwing error messages on devices with no LEDS
>>>>>> at all.
>>>>> This patch makes me wonder what is the policy around issues like this.
>>>>> In fact I've submitted and changes that do the exact opposite :p
>>>>> Like commit: 4630b99d2e93 ("platform/x86: dell-pc: Propagate errors when
>>>>> detecting feature support")
>>>>>
>>>>> IMO missing features should be treated as errors. i.e. The probe should
>>>>> fail.
>>>> IMHO the probe should only fail if some features are deemed essential, like
>>>> required ACPI methods. Optional features like in this case LEDs should be
>>>> handled by the driver in a graceful manner if possible.
>>>>
>>>>> Quoting documentation [1]:
>>>>>
>>>>> 	If a match is found, the device’s driver field is set to the
>>>>> 	driver and the driver’s probe callback is called. This gives the
>>>>> 	driver a chance to verify that it really does support the
>>>>> 	hardware, and that it’s in a working state.
>>>>>
>>>>> And again [2]:
>>>>>
>>>>> 	This callback holds the driver-specific logic to bind the driver
>>>>> 	to a given device. That includes verifying that the device is
>>>>> 	present, that it’s a version the driver can handle, that driver
>>>>> 	data structures can be allocated and initialized, and that any
>>>>> 	hardware can be initialized.
>>>>>
>>>>> Both of these makes me wonder if such a "fail" or error message should
>>>>> be fixed in the first place. In this case the probe correctly checks for
>>>>> device support and fails if it's not found, which is suggested to be the
>>>>> correct behavior.
>>>> The driver should only fail probing if it cannot handle some missing features.
>>>> In this case however both features (audio mute LED and mic mute LED) are completely
>>>> optional and the driver should not fail to load just because one of them is absent.
>>> I agree, both are individually optional, but at least one should be
>>> required.
>>>
>>>> Just think about machines supporting only a single LED (audio or mic mute). Currently
>>>> the driver would fail to load on such devices leaving the users with nothing.
>>> That's very true.
>>>
>>> But I do still think if both fail the probe should still fail. Maybe
>>> there is a way to accomplish this?
>>>
>>> I'm thinking of something like
>>>
>>> if (lenovo_super_hotkey_wmi_led_init(MIC_MUTE, dev) ||
>>>       lenovo_super_hotkey_wmi_led_init(AUDIO_MUTE, dev))
>>>       return -ENODEV;
>>>
>>> What do you think?
>> Normally i would agree to such a thing, but in this case the underlying
>> WMI device
>> supports many more functions that are currently not supported by this
>> driver. Additionally
>> the driver cannot control when the WMI device is registered, so it has
>> to be prepared to
>> encounter a device without the features it supports.
>>
>> Also keep in mind that a failing probe attempt produces a irritating
>> error message.
>>
>>>>> BTW this also leaks `wpriv`, which would remain allocated for no reason.
>>>> wpriv will be freed using devres, so no memory leak here. However i admit that there is
>>>> some room for optimizations, however i leave this to the maintainer of the driver in
>>>> question.
>>> Leak was a bit of an overstatement :) But if both features are missing
>>> it would be kinda leaked, in practice.
>> I see, however i would leave this to the maintainer of the driver
>> because i have no hardware
>> to test the resulting patches :/.
>>
> As a note, I'm on vacation for three weeks and avoiding accessing work emails, so won't be able to discuss this with Jackie properly until I'm back.
>
> For history/context - this particular driver was a bit of a oddity as the Ideapads aren't in the Lenovo Linux program (hope they will be one day). We had a Thinkbook that is using the same LUDS interface, that we were Linux certifying, and LED support is a requirement to work.
>
> I do think this needs revisiting a bit. I am leaning to agreeing that it shouldn't error out - but we were also being careful to not have this cause problems on HW we ourselves don't have access to. It would be nice if it could be extended to more platforms though.
>
> I don't have the specs handy right now (would need to go on the Lenovo VPN for that). Is it OK if we re-visit this when I'm back at home and working?
> Jackie - please do have a look and think about this in the meantime.
>
> Mark

Sure thing, we can wait a bit here. The issue is a purely cosmetic one (error message on devices without both LEDs), so we can take
our time.

Thanks,
Armin Wolf

Re: [PATCH] platform/x86: lenovo-hotkey: Handle missing hardware featuresgracefully

[Jackie Dong]

On 6/30/25 04:36, Mark Pearson wrote:
> Hi Armin & Kurt,
> 
> On Sat, Jun 28, 2025, at 8:01 AM, Armin Wolf wrote:
>> Am 27.06.25 um 23:29 schrieb Kurt Borja:
>>
>>> On Fri Jun 27, 2025 at 6:17 PM -03, Armin Wolf wrote:
>>>> Am 27.06.25 um 22:38 schrieb Kurt Borja:
>>>>
>>>>> Hi Armin,
>>>>>
>>>>> On Fri Jun 27, 2025 at 4:54 PM -03, Armin Wolf wrote:
>>>>>> Not all devices support audio mute and microphone mute LEDs, so the
>>>>>> explicitly checks for hardware support while probing. However missing
>>>>>> hardware features are treated as errors, causing the driver so fail
>>>>>> probing on devices that do not support both LEDs.
>>>>>>
>>>>>> Fix this by simply ignoring hardware features that are not present.
>>>>>> This way the driver will properly load on devices not supporting both
>>>>>> LEDs and will stop throwing error messages on devices with no LEDS
>>>>>> at all.
>>>>> This patch makes me wonder what is the policy around issues like this.
>>>>> In fact I've submitted and changes that do the exact opposite :p
>>>>> Like commit: 4630b99d2e93 ("platform/x86: dell-pc: Propagate errors when
>>>>> detecting feature support")
>>>>>
>>>>> IMO missing features should be treated as errors. i.e. The probe should
>>>>> fail.
>>>> IMHO the probe should only fail if some features are deemed essential, like
>>>> required ACPI methods. Optional features like in this case LEDs should be
>>>> handled by the driver in a graceful manner if possible.
>>>>
>>>>> Quoting documentation [1]:
>>>>>
>>>>> 	If a match is found, the device’s driver field is set to the
>>>>> 	driver and the driver’s probe callback is called. This gives the
>>>>> 	driver a chance to verify that it really does support the
>>>>> 	hardware, and that it’s in a working state.
>>>>>
>>>>> And again [2]:
>>>>>
>>>>> 	This callback holds the driver-specific logic to bind the driver
>>>>> 	to a given device. That includes verifying that the device is
>>>>> 	present, that it’s a version the driver can handle, that driver
>>>>> 	data structures can be allocated and initialized, and that any
>>>>> 	hardware can be initialized.
>>>>>
>>>>> Both of these makes me wonder if such a "fail" or error message should
>>>>> be fixed in the first place. In this case the probe correctly checks for
>>>>> device support and fails if it's not found, which is suggested to be the
>>>>> correct behavior.
>>>> The driver should only fail probing if it cannot handle some missing features.
>>>> In this case however both features (audio mute LED and mic mute LED) are completely
>>>> optional and the driver should not fail to load just because one of them is absent.
>>> I agree, both are individually optional, but at least one should be
>>> required.
>>>
>>>> Just think about machines supporting only a single LED (audio or mic mute). Currently
>>>> the driver would fail to load on such devices leaving the users with nothing.
>>> That's very true.
>>>
>>> But I do still think if both fail the probe should still fail. Maybe
>>> there is a way to accomplish this?
>>>
>>> I'm thinking of something like
>>>
>>> if (lenovo_super_hotkey_wmi_led_init(MIC_MUTE, dev) ||
>>>       lenovo_super_hotkey_wmi_led_init(AUDIO_MUTE, dev))
>>>       return -ENODEV;
>>>
>>> What do you think?
>>
>> Normally i would agree to such a thing, but in this case the underlying
>> WMI device
>> supports many more functions that are currently not supported by this
>> driver. Additionally
>> the driver cannot control when the WMI device is registered, so it has
>> to be prepared to
>> encounter a device without the features it supports.
>>
>> Also keep in mind that a failing probe attempt produces a irritating
>> error message.
>>
>>>>> BTW this also leaks `wpriv`, which would remain allocated for no reason.
>>>> wpriv will be freed using devres, so no memory leak here. However i admit that there is
>>>> some room for optimizations, however i leave this to the maintainer of the driver in
>>>> question.
>>> Leak was a bit of an overstatement :) But if both features are missing
>>> it would be kinda leaked, in practice.
>>
>> I see, however i would leave this to the maintainer of the driver
>> because i have no hardware
>> to test the resulting patches :/.
>>
> 
> As a note, I'm on vacation for three weeks and avoiding accessing work emails, so won't be able to discuss this with Jackie properly until I'm back.
> 
> For history/context - this particular driver was a bit of a oddity as the Ideapads aren't in the Lenovo Linux program (hope they will be one day). We had a Thinkbook that is using the same LUDS interface, that we were Linux certifying, and LED support is a requirement to work.
> 
> I do think this needs revisiting a bit. I am leaning to agreeing that it shouldn't error out - but we were also being careful to not have this cause problems on HW we ourselves don't have access to. It would be nice if it could be extended to more platforms though.
> 
> I don't have the specs handy right now (would need to go on the Lenovo VPN for that). Is it OK if we re-visit this when I'm back at home and working?
> Jackie - please do have a look and think about this in the meantime.
> 
> Mark
> 
> 
Hi Kurt, Armin, Mark,
    I have reviewed the Lenovo Keyboard WMI Specification and find 
GetIfSupportOrVersion method has defined that Output parameters define: 
0 is not support, Non-zero is support.
    As you have noted in previous mail, not all of Lenovo ideapad brand 
laptop support both mic mute LED(on F4) and audio mute LED(on F1). Some 
of them only support one mute LED, some of them don't have any mute LED. 
So, I think that the below codes should be work to handle it. I have 
verified the below codes on Lenovo Yoga Pro7 14APH8(MachineType 82Y8) 
which is only support mic mute LED. In fact, I have gotten user mail 
which describe the same issue on Lenovo Yoga Pro7 14APH8 with 
https://bugzilla.kernel.org/show_bug.cgi?id=220271 which reported this 
issue on MachineType: 81Y3.
    If you have any comment, let me know, I'll update the below patch 
and submit it later.

diff --git a/drivers/platform/x86/lenovo-wmi-hotkey-utilities.c
b/drivers/platform/x86/lenovo-wmi-hotkey-utilities.c
index 89153afd7015..47f5ee34ea71 100644
--- a/drivers/platform/x86/lenovo-wmi-hotkey-utilities.c
+++ b/drivers/platform/x86/lenovo-wmi-hotkey-utilities.c
@@ -122,8 +122,13 @@ static int lenovo_super_hotkey_wmi_led_init(enum
mute_led_type led_type, struct
           return -EIO;

       union acpi_object *obj __free(kfree) = output.pointer;
-    if (obj && obj->type == ACPI_TYPE_INTEGER)
+    if (obj && obj->type == ACPI_TYPE_INTEGER) {
           led_version = obj->integer.value;
+
+        /*Output parameters define: 0 is not support, Non-zero is support*/
+        if (led_version == 0 )
+            return 0;
+    }
       else
           return -EIO;

--
2.43.0

Re: [PATCH] platform/x86: lenovo-hotkey: Handle missing hardware featuresgracefully

[Hans de Goede]

Hi Jackie,

On 7-Jul-25 05:03, Jackie Dong wrote:
> On 6/30/25 04:36, Mark Pearson wrote:
>> Hi Armin & Kurt,
>>
>> On Sat, Jun 28, 2025, at 8:01 AM, Armin Wolf wrote:
>>> Am 27.06.25 um 23:29 schrieb Kurt Borja:
>>>
>>>> On Fri Jun 27, 2025 at 6:17 PM -03, Armin Wolf wrote:
>>>>> Am 27.06.25 um 22:38 schrieb Kurt Borja:
>>>>>
>>>>>> Hi Armin,
>>>>>>
>>>>>> On Fri Jun 27, 2025 at 4:54 PM -03, Armin Wolf wrote:
>>>>>>> Not all devices support audio mute and microphone mute LEDs, so the
>>>>>>> explicitly checks for hardware support while probing. However missing
>>>>>>> hardware features are treated as errors, causing the driver so fail
>>>>>>> probing on devices that do not support both LEDs.
>>>>>>>
>>>>>>> Fix this by simply ignoring hardware features that are not present.
>>>>>>> This way the driver will properly load on devices not supporting both
>>>>>>> LEDs and will stop throwing error messages on devices with no LEDS
>>>>>>> at all.
>>>>>> This patch makes me wonder what is the policy around issues like this.
>>>>>> In fact I've submitted and changes that do the exact opposite :p
>>>>>> Like commit: 4630b99d2e93 ("platform/x86: dell-pc: Propagate errors when
>>>>>> detecting feature support")
>>>>>>
>>>>>> IMO missing features should be treated as errors. i.e. The probe should
>>>>>> fail.
>>>>> IMHO the probe should only fail if some features are deemed essential, like
>>>>> required ACPI methods. Optional features like in this case LEDs should be
>>>>> handled by the driver in a graceful manner if possible.
>>>>>
>>>>>> Quoting documentation [1]:
>>>>>>
>>>>>>     If a match is found, the device’s driver field is set to the
>>>>>>     driver and the driver’s probe callback is called. This gives the
>>>>>>     driver a chance to verify that it really does support the
>>>>>>     hardware, and that it’s in a working state.
>>>>>>
>>>>>> And again [2]:
>>>>>>
>>>>>>     This callback holds the driver-specific logic to bind the driver
>>>>>>     to a given device. That includes verifying that the device is
>>>>>>     present, that it’s a version the driver can handle, that driver
>>>>>>     data structures can be allocated and initialized, and that any
>>>>>>     hardware can be initialized.
>>>>>>
>>>>>> Both of these makes me wonder if such a "fail" or error message should
>>>>>> be fixed in the first place. In this case the probe correctly checks for
>>>>>> device support and fails if it's not found, which is suggested to be the
>>>>>> correct behavior.
>>>>> The driver should only fail probing if it cannot handle some missing features.
>>>>> In this case however both features (audio mute LED and mic mute LED) are completely
>>>>> optional and the driver should not fail to load just because one of them is absent.
>>>> I agree, both are individually optional, but at least one should be
>>>> required.
>>>>
>>>>> Just think about machines supporting only a single LED (audio or mic mute). Currently
>>>>> the driver would fail to load on such devices leaving the users with nothing.
>>>> That's very true.
>>>>
>>>> But I do still think if both fail the probe should still fail. Maybe
>>>> there is a way to accomplish this?
>>>>
>>>> I'm thinking of something like
>>>>
>>>> if (lenovo_super_hotkey_wmi_led_init(MIC_MUTE, dev) ||
>>>>       lenovo_super_hotkey_wmi_led_init(AUDIO_MUTE, dev))
>>>>       return -ENODEV;
>>>>
>>>> What do you think?
>>>
>>> Normally i would agree to such a thing, but in this case the underlying
>>> WMI device
>>> supports many more functions that are currently not supported by this
>>> driver. Additionally
>>> the driver cannot control when the WMI device is registered, so it has
>>> to be prepared to
>>> encounter a device without the features it supports.
>>>
>>> Also keep in mind that a failing probe attempt produces a irritating
>>> error message.
>>>
>>>>>> BTW this also leaks `wpriv`, which would remain allocated for no reason.
>>>>> wpriv will be freed using devres, so no memory leak here. However i admit that there is
>>>>> some room for optimizations, however i leave this to the maintainer of the driver in
>>>>> question.
>>>> Leak was a bit of an overstatement :) But if both features are missing
>>>> it would be kinda leaked, in practice.
>>>
>>> I see, however i would leave this to the maintainer of the driver
>>> because i have no hardware
>>> to test the resulting patches :/.
>>>
>>
>> As a note, I'm on vacation for three weeks and avoiding accessing work emails, so won't be able to discuss this with Jackie properly until I'm back.
>>
>> For history/context - this particular driver was a bit of a oddity as the Ideapads aren't in the Lenovo Linux program (hope they will be one day). We had a Thinkbook that is using the same LUDS interface, that we were Linux certifying, and LED support is a requirement to work.
>>
>> I do think this needs revisiting a bit. I am leaning to agreeing that it shouldn't error out - but we were also being careful to not have this cause problems on HW we ourselves don't have access to. It would be nice if it could be extended to more platforms though.
>>
>> I don't have the specs handy right now (would need to go on the Lenovo VPN for that). Is it OK if we re-visit this when I'm back at home and working?
>> Jackie - please do have a look and think about this in the meantime.
>>
>> Mark
>>
>>
> Hi Kurt, Armin, Mark,
>    I have reviewed the Lenovo Keyboard WMI Specification and find GetIfSupportOrVersion method has defined that Output parameters define: 0 is not support, Non-zero is support.
>    As you have noted in previous mail, not all of Lenovo ideapad brand laptop support both mic mute LED(on F4) and audio mute LED(on F1). Some of them only support one mute LED, some of them don't have any mute LED. So, I think that the below codes should be work to handle it. I have verified the below codes on Lenovo Yoga Pro7 14APH8(MachineType 82Y8) which is only support mic mute LED. In fact, I have gotten user mail which describe the same issue on Lenovo Yoga Pro7 14APH8 with https://bugzilla.kernel.org/show_bug.cgi?id=220271 which reported this issue on MachineType: 81Y3.
>    If you have any comment, let me know, I'll update the below patch and submit it later.
> 
> diff --git a/drivers/platform/x86/lenovo-wmi-hotkey-utilities.c
> b/drivers/platform/x86/lenovo-wmi-hotkey-utilities.c
> index 89153afd7015..47f5ee34ea71 100644
> --- a/drivers/platform/x86/lenovo-wmi-hotkey-utilities.c
> +++ b/drivers/platform/x86/lenovo-wmi-hotkey-utilities.c
> @@ -122,8 +122,13 @@ static int lenovo_super_hotkey_wmi_led_init(enum
> mute_led_type led_type, struct
>           return -EIO;
> 
>       union acpi_object *obj __free(kfree) = output.pointer;
> -    if (obj && obj->type == ACPI_TYPE_INTEGER)
> +    if (obj && obj->type == ACPI_TYPE_INTEGER) {
>           led_version = obj->integer.value;
> +
> +        /*Output parameters define: 0 is not support, Non-zero is support*/
> +        if (led_version == 0 )
> +            return 0;
> +    }
>       else
>           return -EIO;
> 

Thank you that seems like a good change / fix.

We should probably also change this:

        case MIC_MUTE:
                if (led_version != WMI_LUD_SUPPORT_MICMUTE_LED_VER)
                        return -EIO;

into logging a warning and then returning 0 and the same here:

        case AUDIO_MUTE:
                if (led_version != WMI_LUD_SUPPORT_AUDIOMUTE_LED_VER)
                        return -EIO;

Regards,

Hans

Re: [PATCH] platform/x86: lenovo-hotkey: Handle missing hardwarefeaturesgracefully

[Jackie Dong]

Hi Hans,
On 7/7/25 17:22, Hans de Goede wrote:
> Hi Jackie,
> 
> On 7-Jul-25 05:03, Jackie Dong wrote:
>> On 6/30/25 04:36, Mark Pearson wrote:
>>> Hi Armin & Kurt,
>>>
>>> On Sat, Jun 28, 2025, at 8:01 AM, Armin Wolf wrote:
>>>> Am 27.06.25 um 23:29 schrieb Kurt Borja:
>>>>
>>>>> On Fri Jun 27, 2025 at 6:17 PM -03, Armin Wolf wrote:
>>>>>> Am 27.06.25 um 22:38 schrieb Kurt Borja:
>>>>>>
>>>>>>> Hi Armin,
>>>>>>>
>>>>>>> On Fri Jun 27, 2025 at 4:54 PM -03, Armin Wolf wrote:
>>>>>>>> Not all devices support audio mute and microphone mute LEDs, so the
>>>>>>>> explicitly checks for hardware support while probing. However missing
>>>>>>>> hardware features are treated as errors, causing the driver so fail
>>>>>>>> probing on devices that do not support both LEDs.
>>>>>>>>
>>>>>>>> Fix this by simply ignoring hardware features that are not present.
>>>>>>>> This way the driver will properly load on devices not supporting both
>>>>>>>> LEDs and will stop throwing error messages on devices with no LEDS
>>>>>>>> at all.
>>>>>>> This patch makes me wonder what is the policy around issues like this.
>>>>>>> In fact I've submitted and changes that do the exact opposite :p
>>>>>>> Like commit: 4630b99d2e93 ("platform/x86: dell-pc: Propagate errors when
>>>>>>> detecting feature support")
>>>>>>>
>>>>>>> IMO missing features should be treated as errors. i.e. The probe should
>>>>>>> fail.
>>>>>> IMHO the probe should only fail if some features are deemed essential, like
>>>>>> required ACPI methods. Optional features like in this case LEDs should be
>>>>>> handled by the driver in a graceful manner if possible.
>>>>>>
>>>>>>> Quoting documentation [1]:
>>>>>>>
>>>>>>>      If a match is found, the device’s driver field is set to the
>>>>>>>      driver and the driver’s probe callback is called. This gives the
>>>>>>>      driver a chance to verify that it really does support the
>>>>>>>      hardware, and that it’s in a working state.
>>>>>>>
>>>>>>> And again [2]:
>>>>>>>
>>>>>>>      This callback holds the driver-specific logic to bind the driver
>>>>>>>      to a given device. That includes verifying that the device is
>>>>>>>      present, that it’s a version the driver can handle, that driver
>>>>>>>      data structures can be allocated and initialized, and that any
>>>>>>>      hardware can be initialized.
>>>>>>>
>>>>>>> Both of these makes me wonder if such a "fail" or error message should
>>>>>>> be fixed in the first place. In this case the probe correctly checks for
>>>>>>> device support and fails if it's not found, which is suggested to be the
>>>>>>> correct behavior.
>>>>>> The driver should only fail probing if it cannot handle some missing features.
>>>>>> In this case however both features (audio mute LED and mic mute LED) are completely
>>>>>> optional and the driver should not fail to load just because one of them is absent.
>>>>> I agree, both are individually optional, but at least one should be
>>>>> required.
>>>>>
>>>>>> Just think about machines supporting only a single LED (audio or mic mute). Currently
>>>>>> the driver would fail to load on such devices leaving the users with nothing.
>>>>> That's very true.
>>>>>
>>>>> But I do still think if both fail the probe should still fail. Maybe
>>>>> there is a way to accomplish this?
>>>>>
>>>>> I'm thinking of something like
>>>>>
>>>>> if (lenovo_super_hotkey_wmi_led_init(MIC_MUTE, dev) ||
>>>>>        lenovo_super_hotkey_wmi_led_init(AUDIO_MUTE, dev))
>>>>>        return -ENODEV;
>>>>>
>>>>> What do you think?
>>>>
>>>> Normally i would agree to such a thing, but in this case the underlying
>>>> WMI device
>>>> supports many more functions that are currently not supported by this
>>>> driver. Additionally
>>>> the driver cannot control when the WMI device is registered, so it has
>>>> to be prepared to
>>>> encounter a device without the features it supports.
>>>>
>>>> Also keep in mind that a failing probe attempt produces a irritating
>>>> error message.
>>>>
>>>>>>> BTW this also leaks `wpriv`, which would remain allocated for no reason.
>>>>>> wpriv will be freed using devres, so no memory leak here. However i admit that there is
>>>>>> some room for optimizations, however i leave this to the maintainer of the driver in
>>>>>> question.
>>>>> Leak was a bit of an overstatement :) But if both features are missing
>>>>> it would be kinda leaked, in practice.
>>>>
>>>> I see, however i would leave this to the maintainer of the driver
>>>> because i have no hardware
>>>> to test the resulting patches :/.
>>>>
>>>
>>> As a note, I'm on vacation for three weeks and avoiding accessing work emails, so won't be able to discuss this with Jackie properly until I'm back.
>>>
>>> For history/context - this particular driver was a bit of a oddity as the Ideapads aren't in the Lenovo Linux program (hope they will be one day). We had a Thinkbook that is using the same LUDS interface, that we were Linux certifying, and LED support is a requirement to work.
>>>
>>> I do think this needs revisiting a bit. I am leaning to agreeing that it shouldn't error out - but we were also being careful to not have this cause problems on HW we ourselves don't have access to. It would be nice if it could be extended to more platforms though.
>>>
>>> I don't have the specs handy right now (would need to go on the Lenovo VPN for that). Is it OK if we re-visit this when I'm back at home and working?
>>> Jackie - please do have a look and think about this in the meantime.
>>>
>>> Mark
>>>
>>>
>> Hi Kurt, Armin, Mark,
>>     I have reviewed the Lenovo Keyboard WMI Specification and find GetIfSupportOrVersion method has defined that Output parameters define: 0 is not support, Non-zero is support.
>>     As you have noted in previous mail, not all of Lenovo ideapad brand laptop support both mic mute LED(on F4) and audio mute LED(on F1). Some of them only support one mute LED, some of them don't have any mute LED. So, I think that the below codes should be work to handle it. I have verified the below codes on Lenovo Yoga Pro7 14APH8(MachineType 82Y8) which is only support mic mute LED. In fact, I have gotten user mail which describe the same issue on Lenovo Yoga Pro7 14APH8 with https://bugzilla.kernel.org/show_bug.cgi?id=220271 which reported this issue on MachineType: 81Y3.
>>     If you have any comment, let me know, I'll update the below patch and submit it later.
>>
>> diff --git a/drivers/platform/x86/lenovo-wmi-hotkey-utilities.c
>> b/drivers/platform/x86/lenovo-wmi-hotkey-utilities.c
>> index 89153afd7015..47f5ee34ea71 100644
>> --- a/drivers/platform/x86/lenovo-wmi-hotkey-utilities.c
>> +++ b/drivers/platform/x86/lenovo-wmi-hotkey-utilities.c
>> @@ -122,8 +122,13 @@ static int lenovo_super_hotkey_wmi_led_init(enum
>> mute_led_type led_type, struct
>>            return -EIO;
>>
>>        union acpi_object *obj __free(kfree) = output.pointer;
>> -    if (obj && obj->type == ACPI_TYPE_INTEGER)
>> +    if (obj && obj->type == ACPI_TYPE_INTEGER) {
>>            led_version = obj->integer.value;
>> +
>> +        /*Output parameters define: 0 is not support, Non-zero is support*/
>> +        if (led_version == 0 )
>> +            return 0;
>> +    }
>>        else
>>            return -EIO;
>>
> 
> Thank you that seems like a good change / fix.
> 
> We should probably also change this:
> 
>          case MIC_MUTE:
>                  if (led_version != WMI_LUD_SUPPORT_MICMUTE_LED_VER)
>                          return -EIO;
> 
> into logging a warning and then returning 0 and the same here:
> 
>          case AUDIO_MUTE:
>                  if (led_version != WMI_LUD_SUPPORT_AUDIOMUTE_LED_VER)
>                          return -EIO;
> 
> Regards,
> 
> Hans
> 
It's good suggestion and I have updated the patch and submit it in 
another mail.

Thanks a lot,

Jackie Dong