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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DAXLSMRH9E6Y.3Q8Z59YG2B50C@gmail.com>
Date: Fri, 27 Jun 2025 17:38:19 -0300
From: "Kurt Borja" <kuurtb@...il.com>
To: "Armin Wolf" <W_Armin@....de>, <xy-jackie@....com>,
 <alireza.bestboyy@...il.com>, <atescula@...il.com>
Cc: <mpearson-lenovo@...ebb.ca>, <hdegoede@...hat.com>,
 <ilpo.jarvinen@...ux.intel.com>, <platform-driver-x86@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] platform/x86: lenovo-hotkey: Handle missing hardware
 features gracefully

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

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)