--- /dev/null
+From 96e0b355883006554a0bee3697da475971d6bba8 Mon Sep 17 00:00:00 2001
+From: Ross Stutterheim <ross.stutterheim@garmin.com>
+Date: Wed, 16 Apr 2025 14:50:06 +0100
+Subject: ARM: 9447/1: arm/memremap: fix arch_memremap_can_ram_remap()
+
+From: Ross Stutterheim <ross.stutterheim@garmin.com>
+
+commit 96e0b355883006554a0bee3697da475971d6bba8 upstream.
+
+arm/memremap: fix arch_memremap_can_ram_remap()
+
+commit 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure
+presence of linear map") added the definition of
+arch_memremap_can_ram_remap() for arm[64] specific filtering of what pages
+can be used from the linear mapping. memblock_is_map_memory() was called
+with the pfn of the address given to arch_memremap_can_ram_remap();
+however, memblock_is_map_memory() expects to be given an address for arm,
+not a pfn.
+
+This results in calls to memremap() returning a newly mapped area when
+it should return an address in the existing linear mapping.
+
+Fix this by removing the address to pfn translation and pass the
+address directly.
+
+Fixes: 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map")
+Signed-off-by: Ross Stutterheim <ross.stutterheim@garmin.com>
+Cc: Mike Rapoport <rppt@kernel.org>
+Cc: stable@vger.kernel.org
+Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/mm/ioremap.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/arch/arm/mm/ioremap.c
++++ b/arch/arm/mm/ioremap.c
+@@ -515,7 +515,5 @@ void __init early_ioremap_init(void)
+ bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
+ unsigned long flags)
+ {
+- unsigned long pfn = PHYS_PFN(offset);
+-
+- return memblock_is_map_memory(pfn);
++ return memblock_is_map_memory(offset);
+ }
--- /dev/null
+From 7397daf1029d5bfd3415ec8622f5179603d5702d Mon Sep 17 00:00:00 2001
+From: Andreas Kemnade <andreas@kemnade.info>
+Date: Mon, 31 Mar 2025 16:44:39 +0200
+Subject: ARM: omap: pmic-cpcap: do not mess around without CPCAP or OMAP4
+
+From: Andreas Kemnade <andreas@kemnade.info>
+
+commit 7397daf1029d5bfd3415ec8622f5179603d5702d upstream.
+
+The late init call just writes to omap4 registers as soon as
+CONFIG_MFD_CPCAP is enabled without checking whether the
+cpcap driver is actually there or the SoC is indeed an
+OMAP4.
+Rather do these things only with the right device combination.
+
+Fixes booting the BT200 with said configuration enabled and non-factory
+X-Loader and probably also some surprising behavior on other devices.
+
+Fixes: c145649bf262 ("ARM: OMAP2+: Configure voltage controller for cpcap to low-speed")
+CC: stable@vger.kernel.org
+Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
+Reivewed-by: Tony Lindgren <tony@atomide.com>
+Link: https://lore.kernel.org/r/20250331144439.769697-1-andreas@kemnade.info
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/mach-omap2/pmic-cpcap.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/arch/arm/mach-omap2/pmic-cpcap.c
++++ b/arch/arm/mach-omap2/pmic-cpcap.c
+@@ -264,7 +264,11 @@ int __init omap4_cpcap_init(void)
+
+ static int __init cpcap_late_init(void)
+ {
+- omap4_vc_set_pmic_signaling(PWRDM_POWER_RET);
++ if (!of_find_compatible_node(NULL, NULL, "motorola,cpcap"))
++ return 0;
++
++ if (soc_is_omap443x() || soc_is_omap446x() || soc_is_omap447x())
++ omap4_vc_set_pmic_signaling(PWRDM_POWER_RET);
+
+ return 0;
+ }
--- /dev/null
+From 4b634918384c0f84c33aeb4dd9fd4c38e7be5ccb Mon Sep 17 00:00:00 2001
+From: Ryan Roberts <ryan.roberts@arm.com>
+Date: Fri, 30 May 2025 16:23:47 +0100
+Subject: arm64/mm: Close theoretical race where stale TLB entry remains valid
+
+From: Ryan Roberts <ryan.roberts@arm.com>
+
+commit 4b634918384c0f84c33aeb4dd9fd4c38e7be5ccb upstream.
+
+Commit 3ea277194daa ("mm, mprotect: flush TLB if potentially racing with
+a parallel reclaim leaving stale TLB entries") describes a race that,
+prior to the commit, could occur between reclaim and operations such as
+mprotect() when using reclaim's tlbbatch mechanism. See that commit for
+details but the summary is:
+
+"""
+Nadav Amit identified a theoritical race between page reclaim and
+mprotect due to TLB flushes being batched outside of the PTL being held.
+
+He described the race as follows:
+
+ CPU0 CPU1
+ ---- ----
+ user accesses memory using RW PTE
+ [PTE now cached in TLB]
+ try_to_unmap_one()
+ ==> ptep_get_and_clear()
+ ==> set_tlb_ubc_flush_pending()
+ mprotect(addr, PROT_READ)
+ ==> change_pte_range()
+ ==> [ PTE non-present - no flush ]
+
+ user writes using cached RW PTE
+ ...
+
+ try_to_unmap_flush()
+"""
+
+The solution was to insert flush_tlb_batched_pending() in mprotect() and
+friends to explcitly drain any pending reclaim TLB flushes. In the
+modern version of this solution, arch_flush_tlb_batched_pending() is
+called to do that synchronisation.
+
+arm64's tlbbatch implementation simply issues TLBIs at queue-time
+(arch_tlbbatch_add_pending()), eliding the trailing dsb(ish). The
+trailing dsb(ish) is finally issued in arch_tlbbatch_flush() at the end
+of the batch to wait for all the issued TLBIs to complete.
+
+Now, the Arm ARM states:
+
+"""
+The completion of the TLB maintenance instruction is guaranteed only by
+the execution of a DSB by the observer that performed the TLB
+maintenance instruction. The execution of a DSB by a different observer
+does not have this effect, even if the DSB is known to be executed after
+the TLB maintenance instruction is observed by that different observer.
+"""
+
+arch_tlbbatch_add_pending() and arch_tlbbatch_flush() conform to this
+requirement because they are called from the same task (either kswapd or
+caller of madvise(MADV_PAGEOUT)), so either they are on the same CPU or
+if the task was migrated, __switch_to() contains an extra dsb(ish).
+
+HOWEVER, arm64's arch_flush_tlb_batched_pending() is also implemented as
+a dsb(ish). But this may be running on a CPU remote from the one that
+issued the outstanding TLBIs. So there is no architectural gurantee of
+synchonization. Therefore we are still vulnerable to the theoretical
+race described in Commit 3ea277194daa ("mm, mprotect: flush TLB if
+potentially racing with a parallel reclaim leaving stale TLB entries").
+
+Fix this by flushing the entire mm in arch_flush_tlb_batched_pending().
+This aligns with what the other arches that implement the tlbbatch
+feature do.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 43b3dfdd0455 ("arm64: support batched/deferred tlb shootdown during page reclamation/migration")
+Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
+Link: https://lore.kernel.org/r/20250530152445.2430295-1-ryan.roberts@arm.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/include/asm/tlbflush.h | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/arch/arm64/include/asm/tlbflush.h
++++ b/arch/arm64/include/asm/tlbflush.h
+@@ -330,13 +330,14 @@ static inline void arch_tlbbatch_add_pen
+ }
+
+ /*
+- * If mprotect/munmap/etc occurs during TLB batched flushing, we need to
+- * synchronise all the TLBI issued with a DSB to avoid the race mentioned in
+- * flush_tlb_batched_pending().
++ * If mprotect/munmap/etc occurs during TLB batched flushing, we need to ensure
++ * all the previously issued TLBIs targeting mm have completed. But since we
++ * can be executing on a remote CPU, a DSB cannot guarantee this like it can
++ * for arch_tlbbatch_flush(). Our only option is to flush the entire mm.
+ */
+ static inline void arch_flush_tlb_batched_pending(struct mm_struct *mm)
+ {
+- dsb(ish);
++ flush_tlb_mm(mm);
+ }
+
+ /*
--- /dev/null
+From 63fe298652d4eda07d738bfcbbc59d1343a675ef Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Mon, 26 May 2025 11:47:03 +0200
+Subject: ASoC: codecs: wcd9375: Fix double free of regulator supplies
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 63fe298652d4eda07d738bfcbbc59d1343a675ef upstream.
+
+Driver gets regulator supplies in probe path with
+devm_regulator_bulk_get(), so should not call regulator_bulk_free() in
+error and remove paths to avoid double free.
+
+Fixes: 216d04139a6d ("ASoC: codecs: wcd937x: Remove separate handling for vdd-buck supply")
+Cc: stable@vger.kernel.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://patch.msgid.link/20250526-b4-b4-asoc-wcd9395-vdd-px-fixes-v1-3-0b8a2993b7d3@linaro.org
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/codecs/wcd937x.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+--- a/sound/soc/codecs/wcd937x.c
++++ b/sound/soc/codecs/wcd937x.c
+@@ -2897,10 +2897,8 @@ static int wcd937x_probe(struct platform
+ return dev_err_probe(dev, ret, "Failed to get supplies\n");
+
+ ret = regulator_bulk_enable(WCD937X_MAX_BULK_SUPPLY, wcd937x->supplies);
+- if (ret) {
+- regulator_bulk_free(WCD937X_MAX_BULK_SUPPLY, wcd937x->supplies);
++ if (ret)
+ return dev_err_probe(dev, ret, "Failed to enable supplies\n");
+- }
+
+ wcd937x_dt_parse_micbias_info(dev, wcd937x);
+
+@@ -2936,7 +2934,6 @@ static int wcd937x_probe(struct platform
+
+ err_disable_regulators:
+ regulator_bulk_disable(WCD937X_MAX_BULK_SUPPLY, wcd937x->supplies);
+- regulator_bulk_free(WCD937X_MAX_BULK_SUPPLY, wcd937x->supplies);
+
+ return ret;
+ }
+@@ -2953,7 +2950,6 @@ static void wcd937x_remove(struct platfo
+ pm_runtime_dont_use_autosuspend(dev);
+
+ regulator_bulk_disable(WCD937X_MAX_BULK_SUPPLY, wcd937x->supplies);
+- regulator_bulk_free(WCD937X_MAX_BULK_SUPPLY, wcd937x->supplies);
+ }
+
+ #if defined(CONFIG_OF)
--- /dev/null
+From dc59189d32fc3dbddcf418fd4b418fb61f24ade6 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Mon, 26 May 2025 11:47:02 +0200
+Subject: ASoC: codecs: wcd937x: Drop unused buck_supply
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit dc59189d32fc3dbddcf418fd4b418fb61f24ade6 upstream.
+
+Last user of wcd937x_priv->buck_supply was removed in
+commit 216d04139a6d ("ASoC: codecs: wcd937x: Remove separate handling
+for vdd-buck supply").
+
+Fixes: 216d04139a6d ("ASoC: codecs: wcd937x: Remove separate handling for vdd-buck supply")
+Cc: stable@vger.kernel.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://patch.msgid.link/20250526-b4-b4-asoc-wcd9395-vdd-px-fixes-v1-2-0b8a2993b7d3@linaro.org
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/codecs/wcd937x.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/sound/soc/codecs/wcd937x.c
++++ b/sound/soc/codecs/wcd937x.c
+@@ -92,7 +92,6 @@ struct wcd937x_priv {
+ struct regmap_irq_chip *wcd_regmap_irq_chip;
+ struct regmap_irq_chip_data *irq_chip;
+ struct regulator_bulk_data supplies[WCD937X_MAX_BULK_SUPPLY];
+- struct regulator *buck_supply;
+ struct snd_soc_jack *jack;
+ unsigned long status_mask;
+ s32 micb_ref[WCD937X_MAX_MICBIAS];
--- /dev/null
+From a7b3b77fd111d49f8e25624e4ea1046322a57baf Mon Sep 17 00:00:00 2001
+From: Mikko Korhonen <mjkorhon@gmail.com>
+Date: Tue, 17 Jun 2025 09:18:41 +0300
+Subject: ata: ahci: Disallow LPM for Asus B550-F motherboard
+
+From: Mikko Korhonen <mjkorhon@gmail.com>
+
+commit a7b3b77fd111d49f8e25624e4ea1046322a57baf upstream.
+
+Asus ROG STRIX B550-F GAMING (WI-FI) motherboard has problems on some
+SATA ports with at least one hard drive model (WDC WD20EFAX-68FB5N0)
+when LPM is enabled. Disabling LPM solves the issue.
+
+Cc: stable@vger.kernel.org
+Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type")
+Signed-off-by: Mikko Korhonen <mjkorhon@gmail.com>
+Link: https://lore.kernel.org/r/20250617062055.784827-1-mjkorhon@gmail.com
+[cassel: more detailed comment, make single line comments consistent]
+Signed-off-by: Niklas Cassel <cassel@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/ahci.c | 18 +++++++++++++++++-
+ 1 file changed, 17 insertions(+), 1 deletion(-)
+
+--- a/drivers/ata/ahci.c
++++ b/drivers/ata/ahci.c
+@@ -1458,7 +1458,23 @@ static bool ahci_broken_lpm(struct pci_d
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "ASUSPRO D840MB_M840SA"),
+ },
+- /* 320 is broken, there is no known good version yet. */
++ /* 320 is broken, there is no known good version. */
++ },
++ {
++ /*
++ * AMD 500 Series Chipset SATA Controller [1022:43eb]
++ * on this motherboard timeouts on ports 5 and 6 when
++ * LPM is enabled, at least with WDC WD20EFAX-68FB5N0
++ * hard drives. LPM with the same drive works fine on
++ * all other ports on the same controller.
++ */
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR,
++ "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_BOARD_NAME,
++ "ROG STRIX B550-F GAMING (WI-FI)"),
++ },
++ /* 3621 is broken, there is no known good version. */
+ },
+ { } /* terminate list */
+ };
--- /dev/null
+From b5acc3628898baa63658bc4125f9525f9b3dd4f3 Mon Sep 17 00:00:00 2001
+From: Niklas Cassel <cassel@kernel.org>
+Date: Thu, 12 Jun 2025 16:17:51 +0200
+Subject: ata: ahci: Disallow LPM for ASUSPRO-D840SA motherboard
+
+From: Niklas Cassel <cassel@kernel.org>
+
+commit b5acc3628898baa63658bc4125f9525f9b3dd4f3 upstream.
+
+A user has bisected a regression which causes graphical corruptions on his
+screen to commit 7627a0edef54 ("ata: ahci: Drop low power policy board
+type").
+
+Simply reverting commit 7627a0edef54 ("ata: ahci: Drop low power policy
+board type") makes the graphical corruptions on his screen to go away.
+(Note: there are no visible messages in dmesg that indicates a problem
+with AHCI.)
+
+The user also reports that the problem occurs regardless if there is an
+HDD or an SSD connected via AHCI, so the problem is not device related.
+
+The devices also work fine on other motherboards, so it seems specific to
+the ASUSPRO-D840SA motherboard.
+
+While enabling low power modes for AHCI is not supposed to affect
+completely unrelated hardware, like a graphics card, it does however
+allow the system to enter deeper PC-states, which could expose ACPI issues
+that were previously not visible (because the system never entered these
+lower power states before).
+
+There are previous examples where enabling LPM exposed serious BIOS/ACPI
+bugs, see e.g. commit 240630e61870 ("ahci: Disable LPM on Lenovo 50 series
+laptops with a too old BIOS").
+
+Since there hasn't been any BIOS update in years for the ASUSPRO-D840SA
+motherboard, disable LPM for this board, in order to avoid entering lower
+PC-states, which triggers graphical corruptions.
+
+Cc: stable@vger.kernel.org
+Reported-by: Andy Yang <andyybtc79@gmail.com>
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220111
+Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type")
+Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Hans de Goede <hansg@kernel.org>
+Link: https://lore.kernel.org/r/20250612141750.2108342-2-cassel@kernel.org
+Signed-off-by: Niklas Cassel <cassel@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/ahci.c | 19 ++++++++++++++++++-
+ 1 file changed, 18 insertions(+), 1 deletion(-)
+
+--- a/drivers/ata/ahci.c
++++ b/drivers/ata/ahci.c
+@@ -1410,8 +1410,15 @@ static bool ahci_broken_suspend(struct p
+
+ static bool ahci_broken_lpm(struct pci_dev *pdev)
+ {
++ /*
++ * Platforms with LPM problems.
++ * If driver_data is NULL, there is no existing BIOS version with
++ * functioning LPM.
++ * If driver_data is non-NULL, then driver_data contains the DMI BIOS
++ * build date of the first BIOS version with functioning LPM (i.e. older
++ * BIOS versions have broken LPM).
++ */
+ static const struct dmi_system_id sysids[] = {
+- /* Various Lenovo 50 series have LPM issues with older BIOSen */
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+@@ -1446,6 +1453,13 @@ static bool ahci_broken_lpm(struct pci_d
+ */
+ .driver_data = "20180310", /* 2.35 */
+ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_VERSION, "ASUSPRO D840MB_M840SA"),
++ },
++ /* 320 is broken, there is no known good version yet. */
++ },
+ { } /* terminate list */
+ };
+ const struct dmi_system_id *dmi = dmi_first_match(sysids);
+@@ -1455,6 +1469,9 @@ static bool ahci_broken_lpm(struct pci_d
+ if (!dmi)
+ return false;
+
++ if (!dmi->driver_data)
++ return true;
++
+ dmi_get_date(DMI_BIOS_DATE, &year, &month, &date);
+ snprintf(buf, sizeof(buf), "%04d%02d%02d", year, month, date);
+
--- /dev/null
+From d29fc02caad7f94b62d56ee1b01c954f9c961ba7 Mon Sep 17 00:00:00 2001
+From: Tasos Sahanidis <tasos@tasossah.com>
+Date: Mon, 19 May 2025 11:49:45 +0300
+Subject: ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330
+
+From: Tasos Sahanidis <tasos@tasossah.com>
+
+commit d29fc02caad7f94b62d56ee1b01c954f9c961ba7 upstream.
+
+The controller has a hardware bug that can hard hang the system when
+doing ATAPI DMAs without any trace of what happened. Depending on the
+device attached, it can also prevent the system from booting.
+
+In this case, the system hangs when reading the ATIP from optical media
+with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an
+Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,
+running at UDMA/33.
+
+The issue can be reproduced by running the same command with a cygwin
+build of cdrecord on WinXP, although it requires more attempts to cause
+it. The hang in that case is also resolved by forcing PIO. It doesn't
+appear that VIA has produced any drivers for that OS, thus no known
+workaround exists.
+
+HDDs attached to the controller do not suffer from any DMA issues.
+
+Cc: stable@vger.kernel.org
+Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/916677
+Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
+Link: https://lore.kernel.org/r/20250519085508.1398701-1-tasos@tasossah.com
+Signed-off-by: Niklas Cassel <cassel@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/pata_via.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/ata/pata_via.c
++++ b/drivers/ata/pata_via.c
+@@ -368,7 +368,8 @@ static unsigned int via_mode_filter(stru
+ }
+
+ if (dev->class == ATA_DEV_ATAPI &&
+- dmi_check_system(no_atapi_dma_dmi_table)) {
++ (dmi_check_system(no_atapi_dma_dmi_table) ||
++ config->id == PCI_DEVICE_ID_VIA_6415)) {
+ ata_dev_warn(dev, "controller locks up on ATAPI DMA, forcing PIO\n");
+ mask &= ATA_MASK_PIO;
+ }
--- /dev/null
+From f705d33c2f0353039d03e5d6f18f70467d86080e Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <dlemoal@kernel.org>
+Date: Wed, 11 Jun 2025 09:59:15 +0900
+Subject: block: Clear BIO_EMULATES_ZONE_APPEND flag on BIO completion
+
+From: Damien Le Moal <dlemoal@kernel.org>
+
+commit f705d33c2f0353039d03e5d6f18f70467d86080e upstream.
+
+When blk_zone_write_plug_bio_endio() is called for a regular write BIO
+used to emulate a zone append operation, that is, a BIO flagged with
+BIO_EMULATES_ZONE_APPEND, the BIO operation code is restored to the
+original REQ_OP_ZONE_APPEND but the BIO_EMULATES_ZONE_APPEND flag is not
+cleared. Clear it to fully return the BIO to its orginal definition.
+
+Fixes: 9b1ce7f0c6f8 ("block: Implement zone append emulation")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Link: https://lore.kernel.org/r/20250611005915.89843-1-dlemoal@kernel.org
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/blk-zoned.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/block/blk-zoned.c
++++ b/block/blk-zoned.c
+@@ -1240,6 +1240,7 @@ void blk_zone_write_plug_bio_endio(struc
+ if (bio_flagged(bio, BIO_EMULATES_ZONE_APPEND)) {
+ bio->bi_opf &= ~REQ_OP_MASK;
+ bio->bi_opf |= REQ_OP_ZONE_APPEND;
++ bio_clear_flag(bio, BIO_EMULATES_ZONE_APPEND);
+ }
+
+ /*
--- /dev/null
+From 961296e89dc3800e6a3abc3f5d5bb4192cf31e98 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Wed, 11 Jun 2025 08:48:46 -0600
+Subject: block: use plug request list tail for one-shot backmerge attempt
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit 961296e89dc3800e6a3abc3f5d5bb4192cf31e98 upstream.
+
+Previously, the block layer stored the requests in the plug list in
+LIFO order. For this reason, blk_attempt_plug_merge() would check
+just the head entry for a back merge attempt, and abort after that
+unless requests for multiple queues existed in the plug list. If more
+than one request is present in the plug list, this makes the one-shot
+back merging less useful than before, as it'll always fail to find a
+quick merge candidate.
+
+Use the tail entry for the one-shot merge attempt, which is the last
+added request in the list. If that fails, abort immediately unless
+there are multiple queues available. If multiple queues are available,
+then scan the list. Ideally the latter scan would be a backwards scan
+of the list, but as it currently stands, the plug list is singly linked
+and hence this isn't easily feasible.
+
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/linux-block/20250611121626.7252-1-abuehaze@amazon.com/
+Reported-by: Hazem Mohamed Abuelfotoh <abuehaze@amazon.com>
+Fixes: e70c301faece ("block: don't reorder requests in blk_add_rq_to_plug")
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/blk-merge.c | 26 +++++++++++++-------------
+ 1 file changed, 13 insertions(+), 13 deletions(-)
+
+--- a/block/blk-merge.c
++++ b/block/blk-merge.c
+@@ -1180,20 +1180,20 @@ bool blk_attempt_plug_merge(struct reque
+ if (!plug || rq_list_empty(&plug->mq_list))
+ return false;
+
+- rq_list_for_each(&plug->mq_list, rq) {
+- if (rq->q == q) {
+- if (blk_attempt_bio_merge(q, rq, bio, nr_segs, false) ==
+- BIO_MERGE_OK)
+- return true;
+- break;
+- }
++ rq = plug->mq_list.tail;
++ if (rq->q == q)
++ return blk_attempt_bio_merge(q, rq, bio, nr_segs, false) ==
++ BIO_MERGE_OK;
++ else if (!plug->multiple_queues)
++ return false;
+
+- /*
+- * Only keep iterating plug list for merges if we have multiple
+- * queues
+- */
+- if (!plug->multiple_queues)
+- break;
++ rq_list_for_each(&plug->mq_list, rq) {
++ if (rq->q != q)
++ continue;
++ if (blk_attempt_bio_merge(q, rq, bio, nr_segs, false) ==
++ BIO_MERGE_OK)
++ return true;
++ break;
+ }
+ return false;
+ }
--- /dev/null
+From 66db876162155c1cec87359cd78c62aaafde9257 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Wed, 7 May 2025 11:21:22 +0200
+Subject: bus: firewall: Fix missing static inline annotations for stubs
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 66db876162155c1cec87359cd78c62aaafde9257 upstream.
+
+Stubs in the header file for !CONFIG_STM32_FIREWALL case should be both
+static and inline, because they do not come with earlier declaration and
+should be inlined in every unit including the header.
+
+Cc: Patrice Chotard <patrice.chotard@foss.st.com>
+Cc: stable@vger.kernel.org
+Fixes: 5c9668cfc6d7 ("firewall: introduce stm32_firewall framework")
+Link: https://lore.kernel.org/r/20250507092121.95121-2-krzysztof.kozlowski@linaro.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/bus/stm32_firewall_device.h | 15 +++++++++------
+ 1 file changed, 9 insertions(+), 6 deletions(-)
+
+--- a/include/linux/bus/stm32_firewall_device.h
++++ b/include/linux/bus/stm32_firewall_device.h
+@@ -114,27 +114,30 @@ void stm32_firewall_release_access_by_id
+
+ #else /* CONFIG_STM32_FIREWALL */
+
+-int stm32_firewall_get_firewall(struct device_node *np, struct stm32_firewall *firewall,
+- unsigned int nb_firewall)
++static inline int stm32_firewall_get_firewall(struct device_node *np,
++ struct stm32_firewall *firewall,
++ unsigned int nb_firewall)
+ {
+ return -ENODEV;
+ }
+
+-int stm32_firewall_grant_access(struct stm32_firewall *firewall)
++static inline int stm32_firewall_grant_access(struct stm32_firewall *firewall)
+ {
+ return -ENODEV;
+ }
+
+-void stm32_firewall_release_access(struct stm32_firewall *firewall)
++static inline void stm32_firewall_release_access(struct stm32_firewall *firewall)
+ {
+ }
+
+-int stm32_firewall_grant_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id)
++static inline int stm32_firewall_grant_access_by_id(struct stm32_firewall *firewall,
++ u32 subsystem_id)
+ {
+ return -ENODEV;
+ }
+
+-void stm32_firewall_release_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id)
++static inline void stm32_firewall_release_access_by_id(struct stm32_firewall *firewall,
++ u32 subsystem_id)
+ {
+ }
+
--- /dev/null
+From dd7d8e012b23de158ca0188239c7a1f2a83b4484 Mon Sep 17 00:00:00 2001
+From: Ioana Ciornei <ioana.ciornei@nxp.com>
+Date: Tue, 8 Apr 2025 13:58:10 +0300
+Subject: bus: fsl-mc: do not add a device-link for the UAPI used DPMCP device
+
+From: Ioana Ciornei <ioana.ciornei@nxp.com>
+
+commit dd7d8e012b23de158ca0188239c7a1f2a83b4484 upstream.
+
+The fsl-mc bus associated to the root DPRC in a DPAA2 system exports a
+device file for userspace access to the MC firmware. In case the DPRC's
+local MC portal (DPMCP) is currently in use, a new DPMCP device is
+allocated through the fsl_mc_portal_allocate() function.
+
+In this case, the call to fsl_mc_portal_allocate() will fail with -EINVAL
+when trying to add a device link between the root DPRC (consumer) and
+the newly allocated DPMCP device (supplier). This is because the DPMCP
+is a dependent of the DPRC device (the bus).
+
+Fix this by not adding a device link in case the DPMCP is allocated for
+the root DPRC's usage.
+
+Fixes: afb77422819f ("bus: fsl-mc: automatically add a device_link on fsl_mc_[portal,object]_allocate")
+Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20250408105814.2837951-3-ioana.ciornei@nxp.com
+Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bus/fsl-mc/mc-io.c | 19 +++++++++++++------
+ 1 file changed, 13 insertions(+), 6 deletions(-)
+
+--- a/drivers/bus/fsl-mc/mc-io.c
++++ b/drivers/bus/fsl-mc/mc-io.c
+@@ -214,12 +214,19 @@ int __must_check fsl_mc_portal_allocate(
+ if (error < 0)
+ goto error_cleanup_resource;
+
+- dpmcp_dev->consumer_link = device_link_add(&mc_dev->dev,
+- &dpmcp_dev->dev,
+- DL_FLAG_AUTOREMOVE_CONSUMER);
+- if (!dpmcp_dev->consumer_link) {
+- error = -EINVAL;
+- goto error_cleanup_mc_io;
++ /* If the DPRC device itself tries to allocate a portal (usually for
++ * UAPI interaction), don't add a device link between them since the
++ * DPMCP device is an actual child device of the DPRC and a reverse
++ * dependency is not allowed.
++ */
++ if (mc_dev != mc_bus_dev) {
++ dpmcp_dev->consumer_link = device_link_add(&mc_dev->dev,
++ &dpmcp_dev->dev,
++ DL_FLAG_AUTOREMOVE_CONSUMER);
++ if (!dpmcp_dev->consumer_link) {
++ error = -EINVAL;
++ goto error_cleanup_mc_io;
++ }
+ }
+
+ *new_mc_io = mc_io;
--- /dev/null
+From c78230ad34f82c6c0e0e986865073aeeef1f5d30 Mon Sep 17 00:00:00 2001
+From: Wan Junjie <junjie.wan@inceptio.ai>
+Date: Tue, 8 Apr 2025 13:58:11 +0300
+Subject: bus: fsl-mc: fix GET/SET_TAILDROP command ids
+
+From: Wan Junjie <junjie.wan@inceptio.ai>
+
+commit c78230ad34f82c6c0e0e986865073aeeef1f5d30 upstream.
+
+Command ids for taildrop get/set can not pass the check when they are
+using from the restool user space utility. Correct them according to the
+user manual.
+
+Fixes: d67cc29e6d1f ("bus: fsl-mc: list more commands as accepted through the ioctl")
+Signed-off-by: Wan Junjie <junjie.wan@inceptio.ai>
+Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
+Link: https://lore.kernel.org/r/20250408105814.2837951-4-ioana.ciornei@nxp.com
+Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bus/fsl-mc/fsl-mc-uapi.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/bus/fsl-mc/fsl-mc-uapi.c
++++ b/drivers/bus/fsl-mc/fsl-mc-uapi.c
+@@ -275,13 +275,13 @@ static struct fsl_mc_cmd_desc fsl_mc_acc
+ .size = 8,
+ },
+ [DPSW_GET_TAILDROP] = {
+- .cmdid_value = 0x0A80,
++ .cmdid_value = 0x0A90,
+ .cmdid_mask = 0xFFF0,
+ .token = true,
+ .size = 14,
+ },
+ [DPSW_SET_TAILDROP] = {
+- .cmdid_value = 0x0A90,
++ .cmdid_value = 0x0A80,
+ .cmdid_mask = 0xFFF0,
+ .token = true,
+ .size = 24,
--- /dev/null
+From 6f18d174b73d0ceeaa341f46c0986436b3aefc9a Mon Sep 17 00:00:00 2001
+From: Sumit Kumar <quic_sumk@quicinc.com>
+Date: Wed, 9 Apr 2025 16:17:43 +0530
+Subject: bus: mhi: ep: Update read pointer only after buffer is written
+
+From: Sumit Kumar <quic_sumk@quicinc.com>
+
+commit 6f18d174b73d0ceeaa341f46c0986436b3aefc9a upstream.
+
+Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated
+before the buffer is written, potentially causing race conditions where
+the host sees an updated read pointer before the buffer is actually
+written. Updating rd_offset prematurely can lead to the host accessing
+an uninitialized or incomplete element, resulting in data corruption.
+
+Invoke the buffer write before updating rd_offset to ensure the element
+is fully written before signaling its availability.
+
+Fixes: bbdcba57a1a2 ("bus: mhi: ep: Add support for ring management")
+cc: stable@vger.kernel.org
+Co-developed-by: Youssef Samir <quic_yabdulra@quicinc.com>
+Signed-off-by: Youssef Samir <quic_yabdulra@quicinc.com>
+Signed-off-by: Sumit Kumar <quic_sumk@quicinc.com>
+Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
+Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Link: https://patch.msgid.link/20250409-rp_fix-v1-1-8cf1fa22ed28@quicinc.com
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bus/mhi/ep/ring.c | 16 ++++++++++------
+ 1 file changed, 10 insertions(+), 6 deletions(-)
+
+--- a/drivers/bus/mhi/ep/ring.c
++++ b/drivers/bus/mhi/ep/ring.c
+@@ -131,19 +131,23 @@ int mhi_ep_ring_add_element(struct mhi_e
+ }
+
+ old_offset = ring->rd_offset;
+- mhi_ep_ring_inc_index(ring);
+
+ dev_dbg(dev, "Adding an element to ring at offset (%zu)\n", ring->rd_offset);
++ buf_info.host_addr = ring->rbase + (old_offset * sizeof(*el));
++ buf_info.dev_addr = el;
++ buf_info.size = sizeof(*el);
++
++ ret = mhi_cntrl->write_sync(mhi_cntrl, &buf_info);
++ if (ret)
++ return ret;
++
++ mhi_ep_ring_inc_index(ring);
+
+ /* Update rp in ring context */
+ rp = cpu_to_le64(ring->rd_offset * sizeof(*el) + ring->rbase);
+ memcpy_toio((void __iomem *) &ring->ring_ctx->generic.rp, &rp, sizeof(u64));
+
+- buf_info.host_addr = ring->rbase + (old_offset * sizeof(*el));
+- buf_info.dev_addr = el;
+- buf_info.size = sizeof(*el);
+-
+- return mhi_cntrl->write_sync(mhi_cntrl, &buf_info);
++ return ret;
+ }
+
+ void mhi_ep_ring_init(struct mhi_ep_ring *ring, enum mhi_ep_ring_type type, u32 id)
--- /dev/null
+From 4d92e7c5ccadc79764674ffc2c88d329aabbb7e0 Mon Sep 17 00:00:00 2001
+From: Jeffrey Hugo <quic_jhugo@quicinc.com>
+Date: Fri, 28 Mar 2025 10:35:26 -0600
+Subject: bus: mhi: host: Fix conflict between power_up and SYSERR
+
+From: Jeff Hugo <quic_jhugo@quicinc.com>
+
+commit 4d92e7c5ccadc79764674ffc2c88d329aabbb7e0 upstream.
+
+When mhi_async_power_up() enables IRQs, it is possible that we could
+receive a SYSERR notification from the device if the firmware has crashed
+for some reason. Then the SYSERR notification queues a work item that
+cannot execute until the pm_mutex is released by mhi_async_power_up().
+
+So the SYSERR work item will be pending. If mhi_async_power_up() detects
+the SYSERR, it will handle it. If the device is in PBL, then the PBL state
+transition event will be queued, resulting in a work item after the
+pending SYSERR work item. Once mhi_async_power_up() releases the pm_mutex,
+the SYSERR work item can run. It will blindly attempt to reset the MHI
+state machine, which is the recovery action for SYSERR. PBL/SBL are not
+interrupt driven and will ignore the MHI Reset unless SYSERR is actively
+advertised. This will cause the SYSERR work item to timeout waiting for
+reset to be cleared, and will leave the host state in SYSERR processing.
+The PBL transition work item will then run, and immediately fail because
+SYSERR processing is not a valid state for PBL transition.
+
+This leaves the device uninitialized.
+
+This issue has a fairly unique signature in the kernel log:
+
+ mhi mhi3: Requested to power ON
+ Qualcomm Cloud AI 100 0000:36:00.0: Fatal error received from
+ device. Attempting to recover
+ mhi mhi3: Power on setup success
+ mhi mhi3: Device failed to exit MHI Reset state
+ mhi mhi3: Device MHI is not in valid state
+
+We cannot remove the SYSERR handling from mhi_async_power_up() because the
+device may be in the SYSERR state, but we missed the notification as the
+irq was fired before irqs were enabled. We also can't queue the SYSERR work
+item from mhi_async_power_up() if SYSERR is detected because that may
+result in a duplicate work item, and cause the same issue since the
+duplicate item will blindly issue MHI reset even if SYSERR is no longer
+active.
+
+Instead, add a check in the SYSERR work item to make sure that MHI reset is
+only issued if the device is in SYSERR state for PBL or SBL EEs.
+
+Fixes: a6e2e3522f29 ("bus: mhi: core: Add support for PM state transitions")
+Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
+Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Reviewed-by: Troy Hanson <quic_thanson@quicinc.com>
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20250328163526.3365497-1-jeff.hugo@oss.qualcomm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bus/mhi/host/pm.c | 18 +++++++++++++++++-
+ 1 file changed, 17 insertions(+), 1 deletion(-)
+
+--- a/drivers/bus/mhi/host/pm.c
++++ b/drivers/bus/mhi/host/pm.c
+@@ -602,6 +602,7 @@ static void mhi_pm_sys_error_transition(
+ struct mhi_cmd *mhi_cmd;
+ struct mhi_event_ctxt *er_ctxt;
+ struct device *dev = &mhi_cntrl->mhi_dev->dev;
++ bool reset_device = false;
+ int ret, i;
+
+ dev_dbg(dev, "Transitioning from PM state: %s to: %s\n",
+@@ -630,8 +631,23 @@ static void mhi_pm_sys_error_transition(
+ /* Wake up threads waiting for state transition */
+ wake_up_all(&mhi_cntrl->state_event);
+
+- /* Trigger MHI RESET so that the device will not access host memory */
+ if (MHI_REG_ACCESS_VALID(prev_state)) {
++ /*
++ * If the device is in PBL or SBL, it will only respond to
++ * RESET if the device is in SYSERR state. SYSERR might
++ * already be cleared at this point.
++ */
++ enum mhi_state cur_state = mhi_get_mhi_state(mhi_cntrl);
++ enum mhi_ee_type cur_ee = mhi_get_exec_env(mhi_cntrl);
++
++ if (cur_state == MHI_STATE_SYS_ERR)
++ reset_device = true;
++ else if (cur_ee != MHI_EE_PBL && cur_ee != MHI_EE_SBL)
++ reset_device = true;
++ }
++
++ /* Trigger MHI RESET so that the device will not access host memory */
++ if (reset_device) {
+ u32 in_reset = -1;
+ unsigned long timeout = msecs_to_jiffies(mhi_cntrl->timeout_ms);
+
--- /dev/null
+From 54ec8b08216f3be2cc98b33633d3c8ea79749895 Mon Sep 17 00:00:00 2001
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+Date: Wed, 28 May 2025 22:27:12 +0300
+Subject: can: kvaser_pciefd: refine error prone echo_skb_max handling logic
+
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+
+commit 54ec8b08216f3be2cc98b33633d3c8ea79749895 upstream.
+
+echo_skb_max should define the supported upper limit of echo_skb[]
+allocated inside the netdevice's priv. The corresponding size value
+provided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNT
+which is 17.
+
+But later echo_skb_max is rounded up to the nearest power of two (for the
+max case, that would be 32) and the tx/ack indices calculated further
+during tx/rx may exceed the upper array boundary. Kasan reported this for
+the ack case inside kvaser_pciefd_handle_ack_packet(), though the xmit
+function has actually caught the same thing earlier.
+
+ BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528
+ Read of size 8 at addr ffff888105e4f078 by task swapper/4/0
+
+ CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary)
+ Call Trace:
+ <IRQ>
+ dump_stack_lvl lib/dump_stack.c:122
+ print_report mm/kasan/report.c:521
+ kasan_report mm/kasan/report.c:634
+ kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528
+ kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605
+ kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656
+ kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684
+ kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733
+ __handle_irq_event_percpu kernel/irq/handle.c:158
+ handle_irq_event kernel/irq/handle.c:210
+ handle_edge_irq kernel/irq/chip.c:833
+ __common_interrupt arch/x86/kernel/irq.c:296
+ common_interrupt arch/x86/kernel/irq.c:286
+ </IRQ>
+
+Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seq
+numbers' generation that's not the case - we're free to calculate them as
+would be more convenient, not taking tx max count into account. The only
+downside is that the size of echo_skb[] should correspond to the max seq
+number (not tx max count), so in some situations a bit more memory would
+be consumed than could be.
+
+Thus make the size of the underlying echo_skb[] sufficient for the rounded
+max tx value.
+
+Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
+
+Fixes: 8256e0ca6010 ("can: kvaser_pciefd: Fix echo_skb race")
+Cc: stable@vger.kernel.org
+Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
+Link: https://patch.msgid.link/20250528192713.63894-1-pchelkin@ispras.ru
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/can/kvaser_pciefd.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/net/can/kvaser_pciefd.c b/drivers/net/can/kvaser_pciefd.c
+index 7d3066691d5d..52301511ed1b 100644
+--- a/drivers/net/can/kvaser_pciefd.c
++++ b/drivers/net/can/kvaser_pciefd.c
+@@ -966,7 +966,7 @@ static int kvaser_pciefd_setup_can_ctrls(struct kvaser_pciefd *pcie)
+ u32 status, tx_nr_packets_max;
+
+ netdev = alloc_candev(sizeof(struct kvaser_pciefd_can),
+- KVASER_PCIEFD_CAN_TX_MAX_COUNT);
++ roundup_pow_of_two(KVASER_PCIEFD_CAN_TX_MAX_COUNT));
+ if (!netdev)
+ return -ENOMEM;
+
+@@ -995,7 +995,6 @@ static int kvaser_pciefd_setup_can_ctrls(struct kvaser_pciefd *pcie)
+ can->tx_max_count = min(KVASER_PCIEFD_CAN_TX_MAX_COUNT, tx_nr_packets_max - 1);
+
+ can->can.clock.freq = pcie->freq;
+- can->can.echo_skb_max = roundup_pow_of_two(can->tx_max_count);
+ spin_lock_init(&can->lock);
+
+ can->can.bittiming_const = &kvaser_pciefd_bittiming_const;
+--
+2.50.0
+
--- /dev/null
+From db22720545207f734aaa9d9f71637bfc8b0155e0 Mon Sep 17 00:00:00 2001
+From: Brett Werling <brett.werling@garmin.com>
+Date: Thu, 12 Jun 2025 14:18:25 -0500
+Subject: can: tcan4x5x: fix power regulator retrieval during probe
+
+From: Brett Werling <brett.werling@garmin.com>
+
+commit db22720545207f734aaa9d9f71637bfc8b0155e0 upstream.
+
+Fixes the power regulator retrieval in tcan4x5x_can_probe() by ensuring
+the regulator pointer is not set to NULL in the successful return from
+devm_regulator_get_optional().
+
+Fixes: 3814ca3a10be ("can: tcan4x5x: tcan4x5x_can_probe(): turn on the power before parsing the config")
+Signed-off-by: Brett Werling <brett.werling@garmin.com>
+Link: https://patch.msgid.link/20250612191825.3646364-1-brett.werling@garmin.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/can/m_can/tcan4x5x-core.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/can/m_can/tcan4x5x-core.c
++++ b/drivers/net/can/m_can/tcan4x5x-core.c
+@@ -385,10 +385,11 @@ static int tcan4x5x_can_probe(struct spi
+ priv = cdev_to_priv(mcan_class);
+
+ priv->power = devm_regulator_get_optional(&spi->dev, "vsup");
+- if (PTR_ERR(priv->power) == -EPROBE_DEFER) {
+- ret = -EPROBE_DEFER;
+- goto out_m_can_class_free_dev;
+- } else {
++ if (IS_ERR(priv->power)) {
++ if (PTR_ERR(priv->power) == -EPROBE_DEFER) {
++ ret = -EPROBE_DEFER;
++ goto out_m_can_class_free_dev;
++ }
+ priv->power = NULL;
+ }
+
--- /dev/null
+From 060909278cc0a91373a20726bd3d8ce085f480a9 Mon Sep 17 00:00:00 2001
+From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Date: Thu, 16 Jan 2025 16:30:08 -0800
+Subject: ceph: avoid kernel BUG for encrypted inode with unaligned file size
+
+From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+
+commit 060909278cc0a91373a20726bd3d8ce085f480a9 upstream.
+
+The generic/397 test hits a BUG_ON for the case of encrypted inode with
+unaligned file size (for example, 33K or 1K):
+
+[ 877.737811] run fstests generic/397 at 2025-01-03 12:34:40
+[ 877.875761] libceph: mon0 (2)127.0.0.1:40674 session established
+[ 877.876130] libceph: client4614 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949
+[ 877.991965] libceph: mon0 (2)127.0.0.1:40674 session established
+[ 877.992334] libceph: client4617 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949
+[ 878.017234] libceph: mon0 (2)127.0.0.1:40674 session established
+[ 878.017594] libceph: client4620 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949
+[ 878.031394] xfs_io (pid 18988) is setting deprecated v1 encryption policy; recommend upgrading to v2.
+[ 878.054528] libceph: mon0 (2)127.0.0.1:40674 session established
+[ 878.054892] libceph: client4623 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949
+[ 878.070287] libceph: mon0 (2)127.0.0.1:40674 session established
+[ 878.070704] libceph: client4626 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949
+[ 878.264586] libceph: mon0 (2)127.0.0.1:40674 session established
+[ 878.265258] libceph: client4629 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949
+[ 878.374578] -----------[ cut here ]------------
+[ 878.374586] kernel BUG at net/ceph/messenger.c:1070!
+[ 878.375150] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
+[ 878.378145] CPU: 2 UID: 0 PID: 4759 Comm: kworker/2:9 Not tainted 6.13.0-rc5+ #1
+[ 878.378969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
+[ 878.380167] Workqueue: ceph-msgr ceph_con_workfn
+[ 878.381639] RIP: 0010:ceph_msg_data_cursor_init+0x42/0x50
+[ 878.382152] Code: 89 17 48 8b 46 70 55 48 89 47 08 c7 47 18 00 00 00 00 48 89 e5 e8 de cc ff ff 5d 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 0f 0b <0f> 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
+[ 878.383928] RSP: 0018:ffffb4ffc7cbbd28 EFLAGS: 00010287
+[ 878.384447] RAX: ffffffff82bb9ac0 RBX: ffff981390c2f1f8 RCX: 0000000000000000
+[ 878.385129] RDX: 0000000000009000 RSI: ffff981288232b58 RDI: ffff981390c2f378
+[ 878.385839] RBP: ffffb4ffc7cbbe18 R08: 0000000000000000 R09: 0000000000000000
+[ 878.386539] R10: 0000000000000000 R11: 0000000000000000 R12: ffff981390c2f030
+[ 878.387203] R13: ffff981288232b58 R14: 0000000000000029 R15: 0000000000000001
+[ 878.387877] FS: 0000000000000000(0000) GS:ffff9814b7900000(0000) knlGS:0000000000000000
+[ 878.388663] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 878.389212] CR2: 00005e106a0554e0 CR3: 0000000112bf0001 CR4: 0000000000772ef0
+[ 878.389921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 878.390620] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 878.391307] PKRU: 55555554
+[ 878.391567] Call Trace:
+[ 878.391807] <TASK>
+[ 878.392021] ? show_regs+0x71/0x90
+[ 878.392391] ? die+0x38/0xa0
+[ 878.392667] ? do_trap+0xdb/0x100
+[ 878.392981] ? do_error_trap+0x75/0xb0
+[ 878.393372] ? ceph_msg_data_cursor_init+0x42/0x50
+[ 878.393842] ? exc_invalid_op+0x53/0x80
+[ 878.394232] ? ceph_msg_data_cursor_init+0x42/0x50
+[ 878.394694] ? asm_exc_invalid_op+0x1b/0x20
+[ 878.395099] ? ceph_msg_data_cursor_init+0x42/0x50
+[ 878.395583] ? ceph_con_v2_try_read+0xd16/0x2220
+[ 878.396027] ? _raw_spin_unlock+0xe/0x40
+[ 878.396428] ? raw_spin_rq_unlock+0x10/0x40
+[ 878.396842] ? finish_task_switch.isra.0+0x97/0x310
+[ 878.397338] ? __schedule+0x44b/0x16b0
+[ 878.397738] ceph_con_workfn+0x326/0x750
+[ 878.398121] process_one_work+0x188/0x3d0
+[ 878.398522] ? __pfx_worker_thread+0x10/0x10
+[ 878.398929] worker_thread+0x2b5/0x3c0
+[ 878.399310] ? __pfx_worker_thread+0x10/0x10
+[ 878.399727] kthread+0xe1/0x120
+[ 878.400031] ? __pfx_kthread+0x10/0x10
+[ 878.400431] ret_from_fork+0x43/0x70
+[ 878.400771] ? __pfx_kthread+0x10/0x10
+[ 878.401127] ret_from_fork_asm+0x1a/0x30
+[ 878.401543] </TASK>
+[ 878.401760] Modules linked in: hctr2 nhpoly1305_avx2 nhpoly1305_sse2 nhpoly1305 chacha_generic chacha_x86_64 libchacha adiantum libpoly1305 essiv authenc mptcp_diag xsk_diag tcp_diag udp_diag raw_diag inet_diag unix_diag af_packet_diag netlink_diag intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha256_ssse3 sha1_ssse3 aesni_intel joydev crypto_simd cryptd rapl input_leds psmouse sch_fq_codel serio_raw bochs i2c_piix4 floppy qemu_fw_cfg i2c_smbus mac_hid pata_acpi msr parport_pc ppdev lp parport efi_pstore ip_tables x_tables
+[ 878.407319] ---[ end trace 0000000000000000 ]---
+[ 878.407775] RIP: 0010:ceph_msg_data_cursor_init+0x42/0x50
+[ 878.408317] Code: 89 17 48 8b 46 70 55 48 89 47 08 c7 47 18 00 00 00 00 48 89 e5 e8 de cc ff ff 5d 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 0f 0b <0f> 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
+[ 878.410087] RSP: 0018:ffffb4ffc7cbbd28 EFLAGS: 00010287
+[ 878.410609] RAX: ffffffff82bb9ac0 RBX: ffff981390c2f1f8 RCX: 0000000000000000
+[ 878.411318] RDX: 0000000000009000 RSI: ffff981288232b58 RDI: ffff981390c2f378
+[ 878.412014] RBP: ffffb4ffc7cbbe18 R08: 0000000000000000 R09: 0000000000000000
+[ 878.412735] R10: 0000000000000000 R11: 0000000000000000 R12: ffff981390c2f030
+[ 878.413438] R13: ffff981288232b58 R14: 0000000000000029 R15: 0000000000000001
+[ 878.414121] FS: 0000000000000000(0000) GS:ffff9814b7900000(0000) knlGS:0000000000000000
+[ 878.414935] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 878.415516] CR2: 00005e106a0554e0 CR3: 0000000112bf0001 CR4: 0000000000772ef0
+[ 878.416211] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 878.416907] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 878.417630] PKRU: 55555554
+
+(gdb) l *ceph_msg_data_cursor_init+0x42
+0xffffffff823b45a2 is in ceph_msg_data_cursor_init (net/ceph/messenger.c:1070).
+1065
+1066 void ceph_msg_data_cursor_init(struct ceph_msg_data_cursor *cursor,
+1067 struct ceph_msg *msg, size_t length)
+1068 {
+1069 BUG_ON(!length);
+1070 BUG_ON(length > msg->data_length);
+1071 BUG_ON(!msg->num_data_items);
+1072
+1073 cursor->total_resid = length;
+1074 cursor->data = msg->data;
+
+The issue takes place because of this:
+
+[ 202.628853] libceph: net/ceph/messenger_v2.c:2034 prepare_sparse_read_data(): msg->data_length 33792, msg->sparse_read_total 36864
+
+1070 BUG_ON(length > msg->data_length);
+
+The generic/397 test (xfstests) executes such steps:
+(1) create encrypted files and directories;
+(2) access the created files and folders with encryption key;
+(3) access the created files and folders without encryption key.
+
+The issue takes place in this portion of code:
+
+ if (IS_ENCRYPTED(inode)) {
+ struct page **pages;
+ size_t page_off;
+
+ err = iov_iter_get_pages_alloc2(&subreq->io_iter, &pages, len,
+ &page_off);
+ if (err < 0) {
+ doutc(cl, "%llx.%llx failed to allocate pages, %d\n",
+ ceph_vinop(inode), err);
+ goto out;
+ }
+
+ /* should always give us a page-aligned read */
+ WARN_ON_ONCE(page_off);
+ len = err;
+ err = 0;
+
+ osd_req_op_extent_osd_data_pages(req, 0, pages, len, 0, false,
+ false);
+
+The reason of the issue is that subreq->io_iter.count keeps unaligned
+value of length:
+
+[ 347.751182] lib/iov_iter.c:1185 __iov_iter_get_pages_alloc(): maxsize 36864, maxpages 4294967295, start 18446659367320516064
+[ 347.752808] lib/iov_iter.c:1196 __iov_iter_get_pages_alloc(): maxsize 33792, maxpages 4294967295, start 18446659367320516064
+[ 347.754394] lib/iov_iter.c:1015 iter_folioq_get_pages(): maxsize 33792, maxpages 4294967295, extracted 0, _start_offset 18446659367320516064
+
+This patch simply assigns the aligned value to subreq->io_iter.count
+before calling iov_iter_get_pages_alloc2().
+
+[ idryomov: tag the comment with FIXME to make it clear that it's only
+ a workaround for netfslib not coexisting with fscrypt nicely
+ (this is also noted in another pre-existing comment) ]
+
+Cc: David Howells <dhowells@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading")
+Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/addr.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/fs/ceph/addr.c
++++ b/fs/ceph/addr.c
+@@ -396,6 +396,15 @@ static void ceph_netfs_issue_read(struct
+ struct page **pages;
+ size_t page_off;
+
++ /*
++ * FIXME: io_iter.count needs to be corrected to aligned
++ * length. Otherwise, iov_iter_get_pages_alloc2() operates
++ * with the initial unaligned length value. As a result,
++ * ceph_msg_data_cursor_init() triggers BUG_ON() in the case
++ * if msg->sparse_read_total > msg->data_length.
++ */
++ subreq->io_iter.count = len;
++
+ err = iov_iter_get_pages_alloc2(&subreq->io_iter, &pages, len, &page_off);
+ if (err < 0) {
+ doutc(cl, "%llx.%llx failed to allocate pages, %d\n",
--- /dev/null
+From 72386d5245b249f5a0a8fabb881df7ad947b8ea4 Mon Sep 17 00:00:00 2001
+From: Dennis Marttinen <twelho@welho.tech>
+Date: Thu, 29 May 2025 17:45:12 +0000
+Subject: ceph: set superblock s_magic for IMA fsmagic matching
+
+From: Dennis Marttinen <twelho@welho.tech>
+
+commit 72386d5245b249f5a0a8fabb881df7ad947b8ea4 upstream.
+
+The CephFS kernel driver forgets to set the filesystem magic signature in
+its superblock. As a result, IMA policy rules based on fsmagic matching do
+not apply as intended. This causes a major performance regression in Talos
+Linux [1] when mounting CephFS volumes, such as when deploying Rook Ceph
+[2]. Talos Linux ships a hardened kernel with the following IMA policy
+(irrelevant lines omitted):
+
+[...]
+dont_measure fsmagic=0xc36400 # CEPH_SUPER_MAGIC
+[...]
+measure func=FILE_CHECK mask=^MAY_READ euid=0
+measure func=FILE_CHECK mask=^MAY_READ uid=0
+[...]
+
+Currently, IMA compares 0xc36400 == 0x0 for CephFS files, resulting in all
+files opened with O_RDONLY or O_RDWR getting measured with SHA512 on every
+open(2):
+
+10 69990c87e8af323d47e2d6ae4... ima-ng sha512:<hash> /data/cephfs/test-file
+
+Since O_WRONLY is rare, this results in an order of magnitude lower
+performance than expected for practically all file operations. Properly
+setting CEPH_SUPER_MAGIC in the CephFS superblock resolves the regression.
+
+Tests performed on a 3x replicated Ceph v19.3.0 cluster across three
+i5-7200U nodes each equipped with one Micron 7400 MAX M.2 disk (BlueStore)
+and Gigabit ethernet, on Talos Linux v1.10.2:
+
+FS-Mark 3.3
+Test: 500 Files, Empty
+Files/s > Higher Is Better
+6.12.27-talos . 16.6 |====
++twelho patch . 208.4 |====================================================
+
+FS-Mark 3.3
+Test: 500 Files, 1KB Size
+Files/s > Higher Is Better
+6.12.27-talos . 15.6 |=======
++twelho patch . 118.6 |====================================================
+
+FS-Mark 3.3
+Test: 500 Files, 32 Sub Dirs, 1MB Size
+Files/s > Higher Is Better
+6.12.27-talos . 12.7 |===============
++twelho patch . 44.7 |=====================================================
+
+IO500 [3] 2fcd6d6 results (benchmarks within variance omitted):
+
+| IO500 benchmark | 6.12.27-talos | +twelho patch | Speedup |
+|-------------------|----------------|----------------|-----------|
+| mdtest-easy-write | 0.018524 kIOPS | 1.135027 kIOPS | 6027.33 % |
+| mdtest-hard-write | 0.018498 kIOPS | 0.973312 kIOPS | 5161.71 % |
+| ior-easy-read | 0.064727 GiB/s | 0.155324 GiB/s | 139.97 % |
+| mdtest-hard-read | 0.018246 kIOPS | 0.780800 kIOPS | 4179.29 % |
+
+This applies outside of synthetic benchmarks as well, for example, the time
+to rsync a 55 MiB directory with ~12k of mostly small files drops from an
+unusable 10m5s to a reasonable 26s (23x the throughput).
+
+[1]: https://www.talos.dev/
+[2]: https://www.talos.dev/v1.10/kubernetes-guides/configuration/ceph-with-rook/
+[3]: https://github.com/IO500/io500
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Dennis Marttinen <twelho@welho.tech>
+Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/super.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ceph/super.c
++++ b/fs/ceph/super.c
+@@ -1227,6 +1227,7 @@ static int ceph_set_super(struct super_b
+ s->s_time_min = 0;
+ s->s_time_max = U32_MAX;
+ s->s_flags |= SB_NODIRATIME | SB_NOATIME;
++ s->s_magic = CEPH_SUPER_MAGIC;
+
+ ceph_fscrypt_set_ops(s);
+
--- /dev/null
+From 37fb58a7273726e59f9429c89ade5116083a213d Mon Sep 17 00:00:00 2001
+From: Chen Ridong <chenridong@huawei.com>
+Date: Wed, 18 Jun 2025 07:32:17 +0000
+Subject: cgroup,freezer: fix incomplete freezing when attaching tasks
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Chen Ridong <chenridong@huawei.com>
+
+commit 37fb58a7273726e59f9429c89ade5116083a213d upstream.
+
+An issue was found:
+
+ # cd /sys/fs/cgroup/freezer/
+ # mkdir test
+ # echo FROZEN > test/freezer.state
+ # cat test/freezer.state
+ FROZEN
+ # sleep 1000 &
+ [1] 863
+ # echo 863 > test/cgroup.procs
+ # cat test/freezer.state
+ FREEZING
+
+When tasks are migrated to a frozen cgroup, the freezer fails to
+immediately freeze the tasks, causing the cgroup to remain in the
+"FREEZING".
+
+The freeze_task() function is called before clearing the CGROUP_FROZEN
+flag. This causes the freezing() check to incorrectly return false,
+preventing __freeze_task() from being invoked for the migrated task.
+
+To fix this issue, clear the CGROUP_FROZEN state before calling
+freeze_task().
+
+Fixes: f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
+Cc: stable@vger.kernel.org # v6.1+
+Reported-by: Zhong Jiawei <zhongjiawei1@huawei.com>
+Signed-off-by: Chen Ridong <chenridong@huawei.com>
+Acked-by: Michal Koutný <mkoutny@suse.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/cgroup/legacy_freezer.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/kernel/cgroup/legacy_freezer.c
++++ b/kernel/cgroup/legacy_freezer.c
+@@ -188,13 +188,12 @@ static void freezer_attach(struct cgroup
+ if (!(freezer->state & CGROUP_FREEZING)) {
+ __thaw_task(task);
+ } else {
+- freeze_task(task);
+-
+ /* clear FROZEN and propagate upwards */
+ while (freezer && (freezer->state & CGROUP_FROZEN)) {
+ freezer->state &= ~CGROUP_FROZEN;
+ freezer = parent_freezer(freezer);
+ }
++ freeze_task(task);
+ }
+ }
+
media-uvcvideo-return-the-number-of-processed-controls.patch
media-uvcvideo-send-control-events-for-partial-succeeds.patch
media-uvcvideo-fix-deferred-probing-error.patch
+arm64-mm-close-theoretical-race-where-stale-tlb-entry-remains-valid.patch
+arm-9447-1-arm-memremap-fix-arch_memremap_can_ram_remap.patch
+arm-omap-pmic-cpcap-do-not-mess-around-without-cpcap-or-omap4.patch
+asoc-codecs-wcd9375-fix-double-free-of-regulator-supplies.patch
+asoc-codecs-wcd937x-drop-unused-buck_supply.patch
+block-use-plug-request-list-tail-for-one-shot-backmerge-attempt.patch
+block-clear-bio_emulates_zone_append-flag-on-bio-completion.patch
+bus-mhi-ep-update-read-pointer-only-after-buffer-is-written.patch
+bus-mhi-host-fix-conflict-between-power_up-and-syserr.patch
+can-kvaser_pciefd-refine-error-prone-echo_skb_max-handling-logic.patch
+can-tcan4x5x-fix-power-regulator-retrieval-during-probe.patch
+ceph-avoid-kernel-bug-for-encrypted-inode-with-unaligned-file-size.patch
+ceph-set-superblock-s_magic-for-ima-fsmagic-matching.patch
+cgroup-freezer-fix-incomplete-freezing-when-attaching-tasks.patch
+bus-firewall-fix-missing-static-inline-annotations-for-stubs.patch
+ata-pata_via-force-pio-for-atapi-devices-on-vt6415-vt6330.patch
+ata-ahci-disallow-lpm-for-asuspro-d840sa-motherboard.patch
+ata-ahci-disallow-lpm-for-asus-b550-f-motherboard.patch
+bus-fsl-mc-do-not-add-a-device-link-for-the-uapi-used-dpmcp-device.patch
+bus-fsl-mc-fix-get-set_taildrop-command-ids.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
