Re: [PATCH 2/2] platform/arm64: add Lenovo Yoga Slim 7x Gen 11 EC driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Hardware monitoring device registered directly from a platform driver outside of drivers/hwmon/.
- [Low] Missing dependency on CONFIG_INPUT in Kconfig.
--

commit f4e16083031d59790bcde21682359e0fb96b3392
Author: Oleg Keri <okerixx@gmail.com>

platform/arm64: add Lenovo Yoga Slim 7x Gen 11 EC driver

This commit adds a new embedded controller driver for the Lenovo Yoga Slim
7x Gen 11 laptop. It exposes thermistors, battery cell voltages, and CPU
fan speed as hardware monitoring channels, as well as keyboard backlight and
hotkey input events.

> diff --git a/drivers/platform/arm64/Kconfig b/drivers/platform/arm64/Kconfig
> index e32e01b2a9bdd..9d8e875413fa6 100644
> --- a/drivers/platform/arm64/Kconfig
> +++ b/drivers/platform/arm64/Kconfig
> @@ -90,6 +90,28 @@ config EC_LENOVO_THINKPAD_T14S
>  
>  	  Say M or Y here to include this support.
>  
> +config EC_LENOVO_YOGA_SLIM7X_GEN11
> +	tristate "Lenovo Yoga Slim 7x Gen 11 Embedded Controller driver"
> +	depends on ARCH_QCOM || COMPILE_TEST
> +	depends on I2C
> +	depends on HWMON
> +	select NEW_LEDS
> +	select LEDS_CLASS

[Severity: Low]
Does this Kconfig entry need a dependency on INPUT?

If CONFIG_EC_LENOVO_YOGA_SLIM7X_GEN11 is built-in (=y) but CONFIG_INPUT is
built as a module (=m), will this cause a linker error since the driver
unconditionally calls input_register_device() and devm_input_allocate_device()
in yoga_ec_register_keys()?

[ ... ]

> diff --git a/drivers/platform/arm64/lenovo-yoga-slim7x-gen11-ec.c b/drivers/platform/arm64/lenovo-yoga-slim7x-gen11-ec.c
> new file mode 100644
> index 0000000000000..521a7fb8f3562
> --- /dev/null
> +++ b/drivers/platform/arm64/lenovo-yoga-slim7x-gen11-ec.c

[ ... ]

> +static int yoga_ec_probe(struct i2c_client *client)
> +{

[ ... ]

> +	dev_dbg(dev, "thermistors present: %#lx\n", ec->temp_present);
> +
> +	hwmon = devm_hwmon_device_register_with_info(dev, "yoga_slim7x_ec", ec,
> +						     &yoga_ec_chip_info, NULL);

[Severity: Medium]
Does this violate the hardware monitoring subsystem layout rules?

The hwmon architectural guidelines specify that if the main functionality of
a chip is not hardware monitoring, its hardware monitoring functionality
should be implemented as an auxiliary device driver, and that driver should
reside in drivers/hwmon/.

Registering the hwmon device directly from this platform driver in
drivers/platform/arm64/ bypasses these layering boundaries. Should this be
split into an auxiliary device architecture for the hwmon components?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908091752.5508-1-okerixx@gmail.com?part=2