Re: [PATCH 2/2] dt-bindings: leds: Add issi,is31fl3206 to leds-is31fl32xx

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] leds: Missing I2C device ID for is31fl3206 breaks legacy binding and modaliases
- [Low] leds: Double I2C writes during initialization in is31fl32xx_enable_all_channels
--

commit 4f6d324bacf9d9547e9fba515fa86ec07e7ad36d
Author: Flavio Amieiro <flavio@amieiro.net>

leds: is31f132xx: Add support for is31fl3206

This commit adds support for the 12-channel IS31FL3206 variant to the
is31fl32xx led driver series. It introduces a custom enable sequence for the
new chip since its control register layout differs from existing variants.

> diff --git a/drivers/leds/leds-is31fl32xx.c b/drivers/leds/leds-is31fl32xx.c
> index 285085d274538..9c09548acabfa 100644
> --- a/drivers/leds/leds-is31fl32xx.c
> +++ b/drivers/leds/leds-is31fl32xx.c

[ ... ]

> @@ -315,6 +342,33 @@ static int is31fl32xx_reset_regs(struct is31fl32xx_priv *priv)
> +static int is31fl32xx_enable_all_channels(struct is31fl32xx_priv *priv)
> +{
> +	const struct is31fl32xx_chipdef *cdef = priv->cdef;
> +	int ret;
> +
> +	if (cdef->led_control_register_base != IS31FL32XX_REG_NONE) {
> +		u8 value =
> +			GENMASK(cdef->enable_bits_per_led_control_register-1, 0);
> +		u8 num_regs = cdef->channels /
> +			cdef->enable_bits_per_led_control_register;
> +		int i;
> +
> +		for (i = 0; i < num_regs; i++) {
> +			ret = is31fl32xx_write(priv,
> +					       cdef->led_control_register_base+i,
> +					       value);
> +			if (ret)
> +				return ret;
> +		}
> +	}
> +
> +	if (cdef->enable_all_channels_func)
> +		return cdef->enable_all_channels_func(priv);

[Severity: Low]
Does this function perform redundant I2C writes during initialization?

Because the is31fl3206 variant defines a valid led_control_register_base
(0x17), the generic initialization loop executes first, writing 0x01 to the
12 registers.

Immediately following this loop, the custom callback is executed:

	if (cdef->enable_all_channels_func)
		return cdef->enable_all_channels_func(priv);

The custom callback is31fl3206_enable_all_channels() then loops over those
exact same 12 registers and overwrites them with the correct value (0x10).

Should the generic loop be placed in an else block, or should the custom
override function be called first and return early to avoid wasting bus
bandwidth and briefly configuring the chip with incorrect values?

> +
> +	return 0;
> +}

[ ... ]

> @@ -552,7 +594,22 @@ static const struct is31fl32xx_chipdef is31fl3293_cdef = {
>  	.sw_shutdown_func			= is31fl3293_software_shutdown,
>  };
>  
> +static const struct is31fl32xx_chipdef is31fl3206_cdef = {
> +	.channels				= 12,
> +	.shutdown_reg				= 0x00,
> +	.pwm_update_reg			= 0x13,
> +	.global_control_reg			= 0x26,
> +	.reset_reg				= 0x2f,
> +	.output_frequency_setting_reg		= 0x27,
> +	.pwm_register_base			= 0x04,
> +	.led_control_register_base		= 0x17,
> +	.enable_bits_per_led_control_register	= 1,
> +	.brightness_steps			= 256,
> +	.enable_all_channels_func		= is31fl3206_enable_all_channels,
> +};
> +
>  static const struct of_device_id of_is31fl32xx_match[] = {
> +	{ .compatible = "issi,is31fl3206",  .data = &is31fl3206_cdef, },

[Severity: Medium]
Is the new is31fl3206 variant missing from the i2c_device_id table?

While the device tree of_device_id table is updated here, the I2C device ID
array is31fl32xx_id does not appear to have a corresponding entry for
is31fl3206.

Could this prevent the driver from auto-loading on systems that rely on
legacy I2C modaliases, and prevent manual instantiation via the I2C
new_device sysfs interface?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013-add-is31fl3206-support-v1-0-08c066cc241d@amieiro.net?part=2