--- /dev/null
+From 26fe74d598c32e7bc6f150edfc4aa43e1bee55db Mon Sep 17 00:00:00 2001
+From: Christian Hitz <christian.hitz@bbv.ch>
+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 <christian.hitz@bbv.ch>
+
+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 <christian.hitz@bbv.ch>
+Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
+Link: https://patch.msgid.link/20251008123222.1117331-1-christian@klarinett.li
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 5246e3673eeeccb4f5bf4f42375dd495d465ac15 Mon Sep 17 00:00:00 2001
+From: Christian Hitz <christian.hitz@bbv.ch>
+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 <christian.hitz@bbv.ch>
+
+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 <christian.hitz@bbv.ch>
+Link: https://patch.msgid.link/20251022063305.972190-1-christian@klarinett.li
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 1240abf4b71f632f0117b056e22488e4d9808938 Mon Sep 17 00:00:00 2001
+From: Haotian Zhang <vulab@iscas.ac.cn>
+Date: Fri, 31 Oct 2025 14:03:32 +0800
+Subject: media: rc: st_rc: Fix reset control resource leak
+
+From: Haotian Zhang <vulab@iscas.ac.cn>
+
+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 <vulab@iscas.ac.cn>
+Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From ccb7cd3218e48665f3c7e19eede0da5f069c323d Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Thu, 25 Sep 2025 17:02:19 +0200
+Subject: mfd: altera-sysmgr: Fix device leak on sysmgr regmap lookup
+
+From: Johan Hovold <johan@kernel.org>
+
+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 <johan@kernel.org>
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 2bac49bad1f3553cc3b3bfb22cc194e9bd9e8427 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Thu, 23 Oct 2025 12:19:40 +0200
+Subject: mfd: max77620: Fix potential IRQ chip conflict when probing two devices
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+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 <krzysztof.kozlowski@linaro.org>
+Link: https://patch.msgid.link/20251023101939.67991-2-krzysztof.kozlowski@linaro.org
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 894f475f88e06c0f352c829849560790dbdedbe5 Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Wed, 19 Nov 2025 09:50:01 +0100
+Subject: PCI/PM: Reinstate clearing state_saved in legacy and !PM codepaths
+
+From: Lukas Wunner <lukas@wunner.de>
+
+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 <lukas@wunner.de>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
+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 <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
