[PATCH v2] leds: ss4200: Fix typo "retrive" in comment

[PATCH v2] leds: ss4200: Fix typo "retrive" in comment

[Hemanth Selam]

Correct "retrive" to "retrieve", reported by scripts/checkpatch.pl using
the misspelling list in scripts/spelling.txt.  Only touches a comment, no
code changes.

Since v1 the subject carries the driver name and a capitalised
description, to match the LED subsystem convention.

Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
---
 drivers/leds/leds-ss4200.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/leds-ss4200.c b/drivers/leds/leds-ss4200.c
index f24ca75c7cb1..c782339b1330 100644
--- a/drivers/leds/leds-ss4200.c
+++ b/drivers/leds/leds-ss4200.c
@@ -339,7 +339,7 @@ static void ich7_lpc_cleanup(struct device *dev)
 
 /*
  * The OS has determined that the LPC of the Intel ICH7 Southbridge is present
- * so we can retrive the required operational information and prepare the GPIO.
+ * so we can retrieve the required operational information and prepare the GPIO.
  */
 static struct pci_dev *nas_gpio_pci_dev;
 static int ich7_lpc_probe(struct pci_dev *dev,

Re: [PATCH v2] leds: ss4200: Fix typo "retrive" in comment

[sashiko-bot]

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

Pre-existing issues:
- [High] Dereference of uninitialized `nas_gpio_pci_dev` pointer when the driver loads but the PCI device is not probed.
- [High] LED class devices are not unregistered when the PCI device is removed, leading to I/O corruption and dangling sysfs entries.
- [High] The global `nas_gpio_pci_dev` pointer is left dangling if `ich7_lpc_probe` fails.
--

commit ec2db960d9ab8126ad72c0997e1828fad4669f6b
Author: Hemanth Selam <hemanth.selam@gmail.com>

leds: ss4200: Fix typo "retrive" in comment

This commit fixes a typo in a comment from "retrive" to "retrieve" as
reported by checkpatch.pl.

> diff --git a/drivers/leds/leds-ss4200.c b/drivers/leds/leds-ss4200.c
> index fcaa34706b6ca..1b08a40961ba4 100644
> --- a/drivers/leds/leds-ss4200.c
> +++ b/drivers/leds/leds-ss4200.c
> @@ -339,7 +339,7 @@ static void ich7_lpc_cleanup(struct device *dev)
>  
>  /*
>   * The OS has determined that the LPC of the Intel ICH7 Southbridge is present
> - * so we can retrive the required operational information and prepare the GPIO.
> + * so we can retrieve the required operational information and prepare the GPIO.
>   */
>  static struct pci_dev *nas_gpio_pci_dev;

[Severity: High]
This isn't a bug introduced by this patch, but does this code leave the
nas_gpio_pci_dev pointer dangling if probe fails?

In ich7_lpc_probe():

	nas_gpio_pci_dev = dev;
	status = pci_read_config_dword(dev, PMBASE, &g_pm_io_base);
	if (status)
		goto out;

    ...

out:
	if (status) {
		ich7_lpc_cleanup(&dev->dev);
		pci_disable_device(dev);
	}
	return status;

If initialization fails (e.g. request_region() failure), it jumps to the out
label and returns an error without clearing nas_gpio_pci_dev.

[Severity: High]
This is a pre-existing issue, but can this dereference an uninitialized or
invalid pointer on module load?

In nas_gpio_init():

	ret = pci_register_driver(&nas_gpio_pci_driver);
	if (ret)
		return ret;
	for (i = 0; i < ARRAY_SIZE(nasgpio_leds); i++) {
		ret = register_nasgpio_led(i);

And register_nasgpio_led() unconditionally uses the global pointer:

	return led_classdev_register(&nas_gpio_pci_dev->dev, led);

Since pci_register_driver() returns 0 on successful registration with the PCI
core regardless of whether a device was found or successfully probed,
nas_gpio_pci_dev could be NULL (if no hardware bound) or an invalid pointer
(if probe failed), leading to a kernel panic upon dereference.

[Severity: High]
This is a pre-existing issue, but does ich7_lpc_remove() fail to unregister
the active LEDs?

static void ich7_lpc_remove(struct pci_dev *dev)
{
	ich7_lpc_cleanup(&dev->dev);
	pci_disable_device(dev);
}

When the PCI device is removed via sysfs unbind, this function releases the
I/O resources but leaves the LEDs registered. If a user subsequently accesses
the LED sysfs entries, it will trigger I/O port accesses to the released
region, potentially corrupting state if another driver has claimed it.

>  static int ich7_lpc_probe(struct pci_dev *dev,

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