Re: [RFC net-next v2 2/6] leds: rgb: Add IS32FL3207 controller driver

Thank you for your contribution! Sashiko AI review found 2 potential issue(=
s) to consider:
- [Low] The commit message uses a non-standard prefix for the LED subsystem.
- [Low] The driver's private data structure instance uses a generic name in=
stead of the recommended convention.
--

--- Patch [2]: [RFC net-next v2 2/6] leds: rgb: Add IS32FL3207 controller d=
river ---
commit 85f9f1b2acee8fe8b7b8accc04c2fd34496cf682
Author: Ahmad Byagowi <[email protected]>

leds: rgb: Add IS32FL3207 controller driver

This commit adds a generic I2C driver for the Lumissil IS32FL3207 18-channel
LED controller.

> leds: rgb: Add IS32FL3207 controller driver

[Severity: Low]
This isn't a bug, but does the commit message prefix follow the standard na=
ming
conventions? The LED subsystem guidelines specify using leds: <Driver>:
<Capitalized description>. Would leds: is32fl3207: be a more appropriate
prefix here?

> diff --git a/drivers/leds/rgb/leds-is32fl3207.c b/drivers/leds/rgb/leds-i=
s32fl3207.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/leds/rgb/leds-is32fl3207.c
[ ... ]
> @@ -424,6 +424,6 @@ static const struct regmap_config is32fl3207_regmap_c=
onfig =3D {
>  static int is32fl3207_probe(struct i2c_client *client)
>  {
>  	struct device *dev =3D &client->dev;
>  	struct is32fl3207 *chip;

[Severity: Low]
This isn't a bug, but does this code use the recommended variable name for =
the
private data structure instance in is32fl3207_probe()? The LED subsystem
guidelines recommend using ddata instead of generic terms like chip or info.

>  	unsigned int count;

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803205011.1249=
[email protected]?part=3D2