Re: [PATCH v5 2/2] HID: generic: add LampArray support via hid-lamparray helper

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The generic HID driver depends on HID_LAMPARRAY if HID_LAMPARRAY, which forces the core HID generic driver to be a module if the optional LampArray helper is a module.
--

commit de92bcafc34d337da4d9893ee22e49ef91520c6c
Author: Aaron Erhardt <aer@tuxedocomputers.com>

HID: generic: add LampArray support via hid-lamparray helper

The hid-generic driver now optionally registers a lamparray instance after
hid_parse(). LampArray resources are released on driver remove.

> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 4afd80a67b394..a0fcd89c2bb02 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -82,6 +82,7 @@ config UHID
>  
>  config HID_GENERIC
>  	tristate "Generic HID driver"
> +	depends on HID_LAMPARRAY if HID_LAMPARRAY

[Severity: High]
Does this restriction inadvertently force the core generic HID driver to be a
module when the optional LampArray helper is built as a module?

If a system relies on hid-generic for keyboard input during early boot
(e.g., to enter a LUKS decryption password or interact with a panic
shell) and expects the driver to be built-in, forcing it to compile
as a module could result in a total loss of early boot keyboard support.

Could this be avoided by dropping the "depends on" restriction and instead
using IS_REACHABLE(CONFIG_HID_LAMPARRAY) in both the header (for stubs)
and the C file? This would allow a built-in generic driver to gracefully
degrade to stubs while the optional helper remains a module.

>  	default HID
>  	help
>  	Support for generic devices on the HID bus. This includes most
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903073602.3815258-1-aer@tuxedocomputers.com?part=2