From: Greg Kroah-Hartman Date: Mon, 5 Jan 2026 10:42:24 +0000 (+0100) Subject: 5.15-stable patches X-Git-Tag: v6.12.64~40 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9d68b3f91319af2cfc6f966c893a2b39cfeb2ddb;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: leds-leds-lp50xx-allow-led-0-to-be-added-to-module-bank.patch leds-leds-lp50xx-lp5009-supports-3-modules-for-a-total-of-9-leds.patch media-rc-st_rc-fix-reset-control-resource-leak.patch mfd-altera-sysmgr-fix-device-leak-on-sysmgr-regmap-lookup.patch mfd-max77620-fix-potential-irq-chip-conflict-when-probing-two-devices.patch pci-pm-reinstate-clearing-state_saved-in-legacy-and-pm-codepaths.patch --- diff --git a/queue-5.15/leds-leds-lp50xx-allow-led-0-to-be-added-to-module-bank.patch b/queue-5.15/leds-leds-lp50xx-allow-led-0-to-be-added-to-module-bank.patch new file mode 100644 index 0000000000..66dcd89e83 --- /dev/null +++ b/queue-5.15/leds-leds-lp50xx-allow-led-0-to-be-added-to-module-bank.patch @@ -0,0 +1,61 @@ +From 26fe74d598c32e7bc6f150edfc4aa43e1bee55db Mon Sep 17 00:00:00 2001 +From: Christian Hitz +Date: Wed, 8 Oct 2025 14:32:21 +0200 +Subject: leds: leds-lp50xx: Allow LED 0 to be added to module bank + +From: Christian Hitz + +commit 26fe74d598c32e7bc6f150edfc4aa43e1bee55db upstream. + +led_banks contains LED module number(s) that should be grouped into the +module bank. led_banks is 0-initialized. +By checking the led_banks entries for 0, un-set entries are detected. +But a 0-entry also indicates that LED module 0 should be grouped into the +module bank. + +By only iterating over the available entries no check for unused entries +is required and LED module 0 can be added to bank. + +Cc: stable@vger.kernel.org +Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver") +Signed-off-by: Christian Hitz +Reviewed-by: Jacek Anaszewski +Link: https://patch.msgid.link/20251008123222.1117331-1-christian@klarinett.li +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + drivers/leds/leds-lp50xx.c | 10 ++++------ + 1 file changed, 4 insertions(+), 6 deletions(-) + +--- a/drivers/leds/leds-lp50xx.c ++++ b/drivers/leds/leds-lp50xx.c +@@ -347,17 +347,15 @@ out: + return ret; + } + +-static int lp50xx_set_banks(struct lp50xx *priv, u32 led_banks[]) ++static int lp50xx_set_banks(struct lp50xx *priv, u32 led_banks[], int num_leds) + { + u8 led_config_lo, led_config_hi; + u32 bank_enable_mask = 0; + int ret; + int i; + +- for (i = 0; i < priv->chip_info->max_modules; i++) { +- if (led_banks[i]) +- bank_enable_mask |= (1 << led_banks[i]); +- } ++ for (i = 0; i < num_leds; i++) ++ bank_enable_mask |= (1 << led_banks[i]); + + led_config_lo = bank_enable_mask; + led_config_hi = bank_enable_mask >> 8; +@@ -413,7 +411,7 @@ static int lp50xx_probe_leds(struct fwno + return ret; + } + +- ret = lp50xx_set_banks(priv, led_banks); ++ ret = lp50xx_set_banks(priv, led_banks, num_leds); + if (ret) { + dev_err(priv->dev, "Cannot setup banked LEDs\n"); + return ret; diff --git a/queue-5.15/leds-leds-lp50xx-lp5009-supports-3-modules-for-a-total-of-9-leds.patch b/queue-5.15/leds-leds-lp50xx-lp5009-supports-3-modules-for-a-total-of-9-leds.patch new file mode 100644 index 0000000000..a2cf3dd917 --- /dev/null +++ b/queue-5.15/leds-leds-lp50xx-lp5009-supports-3-modules-for-a-total-of-9-leds.patch @@ -0,0 +1,32 @@ +From 5246e3673eeeccb4f5bf4f42375dd495d465ac15 Mon Sep 17 00:00:00 2001 +From: Christian Hitz +Date: Wed, 22 Oct 2025 08:33:04 +0200 +Subject: leds: leds-lp50xx: LP5009 supports 3 modules for a total of 9 LEDs + +From: Christian Hitz + +commit 5246e3673eeeccb4f5bf4f42375dd495d465ac15 upstream. + +LP5009 supports 9 LED outputs that are grouped into 3 modules. + +Cc: stable@vger.kernel.org +Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver") +Signed-off-by: Christian Hitz +Link: https://patch.msgid.link/20251022063305.972190-1-christian@klarinett.li +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + drivers/leds/leds-lp50xx.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/leds/leds-lp50xx.c ++++ b/drivers/leds/leds-lp50xx.c +@@ -56,7 +56,7 @@ + /* There are 3 LED outputs per bank */ + #define LP50XX_LEDS_PER_MODULE 3 + +-#define LP5009_MAX_LED_MODULES 2 ++#define LP5009_MAX_LED_MODULES 3 + #define LP5012_MAX_LED_MODULES 4 + #define LP5018_MAX_LED_MODULES 6 + #define LP5024_MAX_LED_MODULES 8 diff --git a/queue-5.15/media-rc-st_rc-fix-reset-control-resource-leak.patch b/queue-5.15/media-rc-st_rc-fix-reset-control-resource-leak.patch new file mode 100644 index 0000000000..b1e2be35e3 --- /dev/null +++ b/queue-5.15/media-rc-st_rc-fix-reset-control-resource-leak.patch @@ -0,0 +1,39 @@ +From 1240abf4b71f632f0117b056e22488e4d9808938 Mon Sep 17 00:00:00 2001 +From: Haotian Zhang +Date: Fri, 31 Oct 2025 14:03:32 +0800 +Subject: media: rc: st_rc: Fix reset control resource leak + +From: Haotian Zhang + +commit 1240abf4b71f632f0117b056e22488e4d9808938 upstream. + +The driver calls reset_control_get_optional_exclusive() but never calls +reset_control_put() in error paths or in the remove function. This causes +a resource leak when probe fails after successfully acquiring the reset +control, or when the driver is unloaded. + +Switch to devm_reset_control_get_optional_exclusive() to automatically +manage the reset control resource. + +Fixes: a4b80242d046 ("media: st-rc: explicitly request exclusive reset control") +Cc: stable@vger.kernel.org +Signed-off-by: Haotian Zhang +Reviewed-by: Patrice Chotard +Signed-off-by: Sean Young +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/rc/st_rc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/media/rc/st_rc.c ++++ b/drivers/media/rc/st_rc.c +@@ -287,7 +287,7 @@ static int st_rc_probe(struct platform_d + else + rc_dev->rx_base = rc_dev->base; + +- rc_dev->rstc = reset_control_get_optional_exclusive(dev, NULL); ++ rc_dev->rstc = devm_reset_control_get_optional_exclusive(dev, NULL); + if (IS_ERR(rc_dev->rstc)) { + ret = PTR_ERR(rc_dev->rstc); + goto err; diff --git a/queue-5.15/mfd-altera-sysmgr-fix-device-leak-on-sysmgr-regmap-lookup.patch b/queue-5.15/mfd-altera-sysmgr-fix-device-leak-on-sysmgr-regmap-lookup.patch new file mode 100644 index 0000000000..42f52fbaa6 --- /dev/null +++ b/queue-5.15/mfd-altera-sysmgr-fix-device-leak-on-sysmgr-regmap-lookup.patch @@ -0,0 +1,35 @@ +From ccb7cd3218e48665f3c7e19eede0da5f069c323d Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Thu, 25 Sep 2025 17:02:19 +0200 +Subject: mfd: altera-sysmgr: Fix device leak on sysmgr regmap lookup + +From: Johan Hovold + +commit ccb7cd3218e48665f3c7e19eede0da5f069c323d upstream. + +Make sure to drop the reference taken to the sysmgr platform device when +retrieving its driver data. + +Note that holding a reference to a device does not prevent its driver +data from going away. + +Fixes: f36e789a1f8d ("mfd: altera-sysmgr: Add SOCFPGA System Manager") +Cc: stable@vger.kernel.org # 5.2 +Signed-off-by: Johan Hovold +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mfd/altera-sysmgr.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/mfd/altera-sysmgr.c ++++ b/drivers/mfd/altera-sysmgr.c +@@ -118,6 +118,8 @@ struct regmap *altr_sysmgr_regmap_lookup + + sysmgr = dev_get_drvdata(dev); + ++ put_device(dev); ++ + return sysmgr->regmap; + } + EXPORT_SYMBOL_GPL(altr_sysmgr_regmap_lookup_by_phandle); diff --git a/queue-5.15/mfd-max77620-fix-potential-irq-chip-conflict-when-probing-two-devices.patch b/queue-5.15/mfd-max77620-fix-potential-irq-chip-conflict-when-probing-two-devices.patch new file mode 100644 index 0000000000..b7a17d2ebf --- /dev/null +++ b/queue-5.15/mfd-max77620-fix-potential-irq-chip-conflict-when-probing-two-devices.patch @@ -0,0 +1,81 @@ +From 2bac49bad1f3553cc3b3bfb22cc194e9bd9e8427 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Thu, 23 Oct 2025 12:19:40 +0200 +Subject: mfd: max77620: Fix potential IRQ chip conflict when probing two devices + +From: Krzysztof Kozlowski + +commit 2bac49bad1f3553cc3b3bfb22cc194e9bd9e8427 upstream. + +MAX77620 is most likely always a single device on the board, however +nothing stops board designers to have two of them, thus same device +driver could probe twice. Or user could manually try to probing second +time. + +Device driver is not ready for that case, because it allocates +statically 'struct regmap_irq_chip' as non-const and stores during +probe in 'irq_drv_data' member a pointer to per-probe state +container ('struct max77620_chip'). devm_regmap_add_irq_chip() does not +make a copy of 'struct regmap_irq_chip' but store the pointer. + +Second probe - either successful or failure - would overwrite the +'irq_drv_data' from previous device probe, so interrupts would be +executed in a wrong context. + +Cc: stable@vger.kernel.org +Fixes: 3df140d11c6d ("mfd: max77620: Mask/unmask interrupt before/after servicing it") +Signed-off-by: Krzysztof Kozlowski +Link: https://patch.msgid.link/20251023101939.67991-2-krzysztof.kozlowski@linaro.org +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mfd/max77620.c | 15 +++++++++++---- + 1 file changed, 11 insertions(+), 4 deletions(-) + +--- a/drivers/mfd/max77620.c ++++ b/drivers/mfd/max77620.c +@@ -254,7 +254,7 @@ static int max77620_irq_global_unmask(vo + return ret; + } + +-static struct regmap_irq_chip max77620_top_irq_chip = { ++static const struct regmap_irq_chip max77620_top_irq_chip = { + .name = "max77620-top", + .irqs = max77620_top_irqs, + .num_irqs = ARRAY_SIZE(max77620_top_irqs), +@@ -499,6 +499,7 @@ static int max77620_probe(struct i2c_cli + { + const struct regmap_config *rmap_config; + struct max77620_chip *chip; ++ struct regmap_irq_chip *chip_desc; + const struct mfd_cell *mfd_cells; + int n_mfd_cells; + bool pm_off; +@@ -509,6 +510,14 @@ static int max77620_probe(struct i2c_cli + return -ENOMEM; + + i2c_set_clientdata(client, chip); ++ ++ chip_desc = devm_kmemdup(&client->dev, &max77620_top_irq_chip, ++ sizeof(max77620_top_irq_chip), ++ GFP_KERNEL); ++ if (!chip_desc) ++ return -ENOMEM; ++ chip_desc->irq_drv_data = chip; ++ + chip->dev = &client->dev; + chip->chip_irq = client->irq; + chip->chip_id = (enum max77620_chip_id)id->driver_data; +@@ -545,11 +554,9 @@ static int max77620_probe(struct i2c_cli + if (ret < 0) + return ret; + +- max77620_top_irq_chip.irq_drv_data = chip; + ret = devm_regmap_add_irq_chip(chip->dev, chip->rmap, client->irq, + IRQF_ONESHOT | IRQF_SHARED, 0, +- &max77620_top_irq_chip, +- &chip->top_irq_data); ++ chip_desc, &chip->top_irq_data); + if (ret < 0) { + dev_err(chip->dev, "Failed to add regmap irq: %d\n", ret); + return ret; diff --git a/queue-5.15/pci-pm-reinstate-clearing-state_saved-in-legacy-and-pm-codepaths.patch b/queue-5.15/pci-pm-reinstate-clearing-state_saved-in-legacy-and-pm-codepaths.patch new file mode 100644 index 0000000000..b6f9dd773d --- /dev/null +++ b/queue-5.15/pci-pm-reinstate-clearing-state_saved-in-legacy-and-pm-codepaths.patch @@ -0,0 +1,88 @@ +From 894f475f88e06c0f352c829849560790dbdedbe5 Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Wed, 19 Nov 2025 09:50:01 +0100 +Subject: PCI/PM: Reinstate clearing state_saved in legacy and !PM codepaths + +From: Lukas Wunner + +commit 894f475f88e06c0f352c829849560790dbdedbe5 upstream. + +When a PCI device is suspended, it is normally the PCI core's job to save +Config Space and put the device into a low power state. However drivers +are allowed to assume these responsibilities. When they do, the PCI core +can tell by looking at the state_saved flag in struct pci_dev: The flag +is cleared before commencing the suspend sequence and it is set when +pci_save_state() is called. If the PCI core finds the flag set late in +the suspend sequence, it refrains from calling pci_save_state() itself. + +But there are two corner cases where the PCI core neglects to clear the +flag before commencing the suspend sequence: + +* If a driver has legacy PCI PM callbacks, pci_legacy_suspend() neglects + to clear the flag. The (stale) flag is subsequently queried by + pci_legacy_suspend() itself and pci_legacy_suspend_late(). + +* If a device has no driver or its driver has no PCI PM callbacks, + pci_pm_freeze() neglects to clear the flag. The (stale) flag is + subsequently queried by pci_pm_freeze_noirq(). + +The flag may be set prior to suspend if the device went through error +recovery: Drivers commonly invoke pci_restore_state() + pci_save_state() +to restore Config Space after reset. + +The flag may also be set if drivers call pci_save_state() on probe to +allow for recovery from subsequent errors. + +The result is that pci_legacy_suspend_late() and pci_pm_freeze_noirq() +don't call pci_save_state() and so the state that will be restored on +resume is the one recorded on last error recovery or on probe, not the one +that the device had on suspend. If the two states happen to be identical, +there's no problem. + +Reinstate clearing the flag in pci_legacy_suspend() and pci_pm_freeze(). +The two functions used to do that until commit 4b77b0a2ba27 ("PCI: Clear +saved_state after the state has been restored") deemed it unnecessary +because it assumed that it's sufficient to clear the flag on resume in +pci_restore_state(). The commit seemingly did not take into account that +pci_save_state() and pci_restore_state() are not only used by power +management code, but also for error recovery. + +Devices without driver or whose driver has no PCI PM callbacks may be in +runtime suspend when pci_pm_freeze() is called. Their state has already +been saved, so don't clear the flag to skip a pointless pci_save_state() +in pci_pm_freeze_noirq(). + +None of the drivers with legacy PCI PM callbacks seem to use runtime PM, +so clear the flag unconditionally in their case. + +Fixes: 4b77b0a2ba27 ("PCI: Clear saved_state after the state has been restored") +Signed-off-by: Lukas Wunner +Signed-off-by: Bjorn Helgaas +Reviewed-by: Rafael J. Wysocki (Intel) +Cc: stable@vger.kernel.org # v2.6.32+ +Link: https://patch.msgid.link/094f2aad64418710daf0940112abe5a0afdc6bce.1763483367.git.lukas@wunner.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/pci-driver.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/pci/pci-driver.c ++++ b/drivers/pci/pci-driver.c +@@ -598,6 +598,8 @@ static int pci_legacy_suspend(struct dev + struct pci_dev *pci_dev = to_pci_dev(dev); + struct pci_driver *drv = pci_dev->driver; + ++ pci_dev->state_saved = false; ++ + if (drv && drv->suspend) { + pci_power_t prev = pci_dev->current_state; + int error; +@@ -999,6 +1001,8 @@ static int pci_pm_freeze(struct device * + + if (!pm) { + pci_pm_default_suspend(pci_dev); ++ if (!pm_runtime_suspended(dev)) ++ pci_dev->state_saved = false; + return 0; + } + diff --git a/queue-5.15/series b/queue-5.15/series index 24141b42a3..0e42ef96ac 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -379,3 +379,9 @@ iommu-omap-fix-device-leaks-on-probe_device.patch iommu-sun50i-fix-device-leak-on-of_xlate.patch iommu-tegra-fix-device-leak-on-probe_device.patch hid-logitech-dj-remove-duplicate-error-logging.patch +pci-pm-reinstate-clearing-state_saved-in-legacy-and-pm-codepaths.patch +leds-leds-lp50xx-allow-led-0-to-be-added-to-module-bank.patch +leds-leds-lp50xx-lp5009-supports-3-modules-for-a-total-of-9-leds.patch +mfd-altera-sysmgr-fix-device-leak-on-sysmgr-regmap-lookup.patch +mfd-max77620-fix-potential-irq-chip-conflict-when-probing-two-devices.patch +media-rc-st_rc-fix-reset-control-resource-leak.patch