[PATCH v2 1/4] leds: cobalt-raq: add missing MODULE_DESCRIPTION

[PATCH v2 1/4] leds: cobalt-raq: add missing MODULE_DESCRIPTION

[Arunachalam]

Add the missing MODULE_DESCRIPTION() macro, which is required by
modpost and was missing from this driver.

Signed-off-by: Arunachalam <arun07172003@gmail.com>
---
 drivers/leds/leds-cobalt-raq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/leds-cobalt-raq.c b/drivers/leds/leds-cobalt-raq.c
index 045c239c7..5b5acaa8c 100644
--- a/drivers/leds/leds-cobalt-raq.c
+++ b/drivers/leds/leds-cobalt-raq.c
@@ -101,5 +101,5 @@ static struct platform_driver cobalt_raq_led_driver = {
 		.name	= "cobalt-raq-leds",
 	},
 };
-
+MODULE_DESCRIPTION("LEDs driver for the Cobalt Raq series");
 builtin_platform_driver(cobalt_raq_led_driver);
-- 
2.39.5

[PATCH v2 2/4] leds: lp8788: convert to dev_err_probe()

[Arunachalam]

Replace open-coded dev_err() + return patterns with dev_err_probe(),
which also handles -EPROBE_DEFER correctly.

Signed-off-by: Arunachalam <arun07172003@gmail.com>
---
 drivers/leds/leds-lp8788.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/leds/leds-lp8788.c b/drivers/leds/leds-lp8788.c
index 9b9525ccc..259ac50e8 100644
--- a/drivers/leds/leds-lp8788.c
+++ b/drivers/leds/leds-lp8788.c
@@ -143,16 +143,12 @@ static int lp8788_led_probe(struct platform_device *pdev)
 	mutex_init(&led->lock);
 
 	ret = lp8788_led_init_device(led, led_pdata);
-	if (ret) {
-		dev_err(dev, "led init device err: %d\n", ret);
-		return ret;
-	}
+	if (ret)
+		return dev_err_probe(dev, ret, "led init device err\n");
 
 	ret = devm_led_classdev_register(dev, &led->led_dev);
-	if (ret) {
-		dev_err(dev, "led register err: %d\n", ret);
-		return ret;
-	}
+	if (ret)
+		return dev_err_probe(dev, ret, "led register err\n");
 
 	return 0;
 }
-- 
2.39.5

Re: [PATCH v2 2/4] leds: lp8788: convert to dev_err_probe()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Low] The commit message description is not capitalized, violating the LED subsystem guidelines.

Pre-existing issues:
- [High] The driver directly mutates a global static configuration structure during initialization, causing cross-contamination between devices or across probes.
--

--- Patch [2]: [PATCH v2 2/4] leds: lp8788: convert to dev_err_probe() ---
commit 757b3eb36736561a1f3fc533b95dcae04a897dbc
Author: Arunachalam <arun07172003@gmail.com>

leds: lp8788: convert to dev_err_probe()

This patch replaces open-coded dev_err() and return sequences with
dev_err_probe() in the lp8788 driver. It improves error handling and properly
manages deferred probing.

> leds: lp8788: convert to dev_err_probe()

[Severity: Low]
This isn't a bug, but should the word "convert" be capitalized to match
the LED subsystem commit naming conventions?

> diff --git a/drivers/leds/leds-lp8788.c b/drivers/leds/leds-lp8788.c
> index 9b9525ccca157..259ac50e8498f 100644
> --- a/drivers/leds/leds-lp8788.c
> +++ b/drivers/leds/leds-lp8788.c
> @@ -143,16 +143,12 @@ static int lp8788_led_probe(struct platform_device *pdev)
>  	mutex_init(&led->lock);
>  
>  	ret = lp8788_led_init_device(led, led_pdata);

[Severity: High]
This is a pre-existing issue, but does modifying the global configuration 
structure cause cross-contamination between devices?

Looking at lp8788_led_init_device() in drivers/leds/leds-lp8788.c:

static int lp8788_led_init_device(struct lp8788_led *led,
                                  struct lp8788_led_platform_data *pdata)
{
        struct lp8788_led_config *cfg = &default_led_config;
        ...
        if (pdata) {
                cfg->scale = pdata->scale;
                cfg->num = pdata->num;
                cfg->iout = pdata->iout_code;
        }

If there are multiple instances, modifying cfg (which points to the
global default_led_config) might cause subsequent instances without platform
data to inherit the mutated configuration rather than the defaults. Could
we make a local copy of the configuration instead?

> -	if (ret) {
> -		dev_err(dev, "led init device err: %d\n", ret);
> -		return ret;
> -	}
> +	if (ret)
> +		return dev_err_probe(dev, ret, "led init device err\n");

[ ... ]

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

[PATCH v2 3/4] leds: menf21bmc: convert to dev_err_probe()

[Arunachalam]

Replace open-coded dev_err() + return pattern with dev_err_probe(),
which also handles -EPROBE_DEFER correctly.

Signed-off-by: Arunachalam <arun07172003@gmail.com>
---
 drivers/leds/leds-menf21bmc.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c
index 6b1b47160..a7e4db487 100644
--- a/drivers/leds/leds-menf21bmc.c
+++ b/drivers/leds/leds-menf21bmc.c
@@ -84,10 +84,8 @@ static int menf21bmc_led_probe(struct platform_device *pdev)
 		leds[i].cdev.brightness_set = menf21bmc_led_set;
 		leds[i].i2c_client = i2c_client;
 		ret = devm_led_classdev_register(&pdev->dev, &leds[i].cdev);
-		if (ret < 0) {
-			dev_err(&pdev->dev, "failed to register LED device\n");
-			return ret;
-		}
+		if (ret < 0)
+			return dev_err_probe(&pdev->dev, ret, "failed to register LED device\n");
 	}
 	dev_info(&pdev->dev, "MEN 140F21P00 BMC LED device enabled\n");
 
-- 
2.39.5

Re: [PATCH v2 3/4] leds: menf21bmc: convert to dev_err_probe()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Low] The commit message description is not capitalized.

Pre-existing issues:
- [Critical] The driver manages LED instances using a shared static global array `leds`, causing kernel list corruption and use-after-free crashes if multiple devices probe or unbind.
- [High] The LED brightness control callback `menf21bmc_led_set` sleeps but is incorrectly assigned to the non-blocking `brightness_set` hook.
--

--- Patch [3]: [PATCH v2 3/4] leds: menf21bmc: convert to dev_err_probe() ---
commit 256232e59da7fa918a47e5b2a0fabb6d2df03b37
Author: Arunachalam <arun07172003@gmail.com>

leds: menf21bmc: convert to dev_err_probe()
    
Replace open-coded dev_err() + return pattern with dev_err_probe(),
which also handles -EPROBE_DEFER correctly.

> leds: menf21bmc: convert to dev_err_probe()

[Severity: Low]
This isn't a bug introduced by this patch, but subsystem guidelines mandate
that the description after the subsystem prefix must be capitalized for LED
drivers. Should this be "Convert to dev_err_probe()"?

> diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c
> index 6b1b471606026..a7e4db4879d81 100644
> --- a/drivers/leds/leds-menf21bmc.c
> +++ b/drivers/leds/leds-menf21bmc.c
> @@ -84,10 +84,8 @@ static int menf21bmc_led_probe(struct platform_device *pdev)
>  		leds[i].cdev.brightness_set = menf21bmc_led_set;

[Severity: High]
This is a pre-existing issue, but does assigning menf21bmc_led_set to the
non-blocking brightness_set hook risk a scheduling while atomic panic?

If the LED is set to blink via sysfs, led_timer_function executes in atomic
softirq context and calls this brightness_set callback. However,
menf21bmc_led_set() takes a mutex and performs I2C transactions which can
sleep.

Should this be assigned to brightness_set_blocking instead?

>  		leds[i].i2c_client = i2c_client;
>  		ret = devm_led_classdev_register(&pdev->dev, &leds[i].cdev);

[Severity: Critical]
This is a pre-existing issue, but does registering a globally shared static
cdev object risk linked list corruption?

The driver manages LED instances using a single static global array (leds).
If multiple devices are probed or if a user unbinds and rebinds the device,
devm_led_classdev_register() will be called on the same leds[i].cdev
structure.

The LED core calls list_add_tail() on a node already in a linked list, which
corrupts the global leds_list.

> -		if (ret < 0) {
> -			dev_err(&pdev->dev, "failed to register LED device\n");
> -			return ret;
> -		}
> +		if (ret < 0)
> +			return dev_err_probe(&pdev->dev, ret, "failed to register LED device\n");
>  	}
>  	dev_info(&pdev->dev, "MEN 140F21P00 BMC LED device enabled\n");

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723164612.3146-1-arun07172003@gmail.com?part=3

[PATCH v2 4/4] leds: 88pm860x: convert to dev_err_probe()

[Arunachalam]

Replace open-coded dev_err() + return patterns with dev_err_probe(),
which also handles -EPROBE_DEFER correctly.

Signed-off-by: Arunachalam <arun07172003@gmail.com>
---
 drivers/leds/leds-88pm860x.c | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/leds/leds-88pm860x.c b/drivers/leds/leds-88pm860x.c
index ef5c6c466..65f2af134 100644
--- a/drivers/leds/leds-88pm860x.c
+++ b/drivers/leds/leds-88pm860x.c
@@ -152,16 +152,12 @@ static int pm860x_led_probe(struct platform_device *pdev)
 	if (data == NULL)
 		return -ENOMEM;
 	res = platform_get_resource_byname(pdev, IORESOURCE_REG, "control");
-	if (!res) {
-		dev_err(&pdev->dev, "No REG resource for control\n");
-		return -ENXIO;
-	}
+	if (!res)
+		return dev_err_probe(&pdev->dev, -ENXIO, "No REG resource for control\n");
 	data->reg_control = res->start;
 	res = platform_get_resource_byname(pdev, IORESOURCE_REG, "blink");
-	if (!res) {
-		dev_err(&pdev->dev, "No REG resource for blink\n");
-		return -ENXIO;
-	}
+	if (!res)
+		return dev_err_probe(&pdev->dev, -ENXIO, "No REG resource for blink\n");
 	data->reg_blink = res->start;
 	memset(data->name, 0, MFD_NAME_SIZE);
 	switch (pdev->id) {
@@ -203,10 +199,8 @@ static int pm860x_led_probe(struct platform_device *pdev)
 	mutex_init(&data->lock);
 
 	ret = led_classdev_register(chip->dev, &data->cdev);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "Failed to register LED: %d\n", ret);
-		return ret;
-	}
+	if (ret < 0)
+		return dev_err_probe(&pdev->dev, ret, "Failed to register LED\n");
 	pm860x_led_set(&data->cdev, 0);
 
 	platform_set_drvdata(pdev, data);
-- 
2.39.5

Re: [PATCH v2 4/4] leds: 88pm860x: convert to dev_err_probe()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The commit message lacks the mandatory subsystem prefix capitalization.
--

--- Patch [4]: [PATCH v2 4/4] leds: 88pm860x: convert to dev_err_probe() ---
commit 44af50244a910d0907f1e33477c8de6960595c9a
Author: Arunachalam <arun07172003@gmail.com>

leds: 88pm860x: convert to dev_err_probe()

This commit replaces open-coded dev_err() and return patterns with
dev_err_probe(), which also properly handles -EPROBE_DEFER.

> leds: 88pm860x: convert to dev_err_probe()

[Severity: Low]
This isn't a bug, but the description after the subsystem and driver
prefixes should be capitalized according to the LED subsystem commit
message conventions. Should this be "leds: 88pm860x: Convert to
dev_err_probe()"?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723164612.3146-1-arun07172003@gmail.com?part=4

Re: [PATCH v2 1/4] leds: cobalt-raq: add missing MODULE_DESCRIPTION

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Low] The commit message claims MODULE_DESCRIPTION is required by modpost for this driver, but the driver is unconditionally built-in.
- [Low] The commit message description is not capitalized, violating subsystem guidelines.

Pre-existing issues:
- [High] Unmanaged LED registration combined with managed memory mapping without a `.remove` callback leads to a use-after-free on device unbind.
--

--- Patch [1]: [PATCH v2 1/4] leds: cobalt-raq: add missing MODULE_DESCRIPTION ---
commit f1b0026d062cbcf0e980882e66d901b8eb8e018f
Author: Arunachalam <arun07172003@gmail.com>

leds: cobalt-raq: add missing MODULE_DESCRIPTION

Add the missing MODULE_DESCRIPTION() macro, which is required by
modpost and was missing from this driver.

> leds: cobalt-raq: add missing MODULE_DESCRIPTION

[Severity: Low]
This isn't a bug, but the subsystem guidelines request capitalizing the
description after the prefix. Should this be "Add missing MODULE_DESCRIPTION"?

> Add the missing MODULE_DESCRIPTION() macro, which is required by
> modpost and was missing from this driver.

[Severity: Low]
Is this description accurate? This driver is defined as a bool in Kconfig,
meaning it can only be built-in. Modpost only checks for MODULE_DESCRIPTION
in loadable modules, so is this macro actually required here?

> diff --git a/drivers/leds/leds-cobalt-raq.c b/drivers/leds/leds-cobalt-raq.c
> index 045c239c7328e..5b5acaa8c3215 100644
> --- a/drivers/leds/leds-cobalt-raq.c
> +++ b/drivers/leds/leds-cobalt-raq.c
> @@ -101,5 +101,5 @@ static struct platform_driver cobalt_raq_led_driver = {
>  		.name	= "cobalt-raq-leds",
>  	},
>  };

[Severity: High]
This is a pre-existing issue, but does the lack of a .remove callback here
leave a use-after-free window?

If a privileged user unbinds the driver via sysfs, the driver core will
automatically release devm resources, unmapping led_port. Since the LEDs were
registered with led_classdev_register() in cobalt_raq_led_probe() without
using the managed API, they remain registered.

Would a subsequent write to the LED's brightness file trigger
raq_web_led_set() and write to the now-unmapped led_port?

> -
> +MODULE_DESCRIPTION("LEDs driver for the Cobalt Raq series");
>  builtin_platform_driver(cobalt_raq_led_driver);

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