Linux-stable-mirror August 2025

linux-stable-mirror@lists.linaro.org

518 participants
1331 discussions

[PATCH v8] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw

by Shuai Zhang

When the host actively triggers SSR and collects coredump data, the Bluetooth stack sends a reset command to the controller. However, due to the inability to clear the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits, the reset command times out. To address this, this patch clears the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED flags and adds a 50ms delay after SSR, but only when HCI_QUIRK_NON_PERSISTENT_SETUP is not set. This ensures the controller completes the SSR process when BT_EN is always high due to hardware. For the purpose of HCI_QUIRK_NON_PERSISTENT_SETUP, please refer to the comment in `include/net/bluetooth/hci.h`. The HCI_QUIRK_NON_PERSISTENT_SETUP quirk is associated with BT_EN, and its presence can be used to determine whether BT_EN is defined in DTS. After SSR, host will not download the firmware, causing controller to remain in the IBS_WAKE state. Host needs to synchronize with the controller to maintain proper operation. Multiple triggers of SSR only first generate coredump file, due to memcoredump_flag no clear. add clear coredump flag when ssr completed. When the SSR duration exceeds 2 seconds, it triggers host tx_idle_timeout, which sets host TX state to sleep. due to the hardware pulling up bt_en, the firmware is not downloaded after the SSR. As a result, the controller does not enter sleep mode. Consequently, when the host sends a command afterward, it sends 0xFD to the controller, but the controller does not respond, leading to a command timeout. So reset tx_idle_timer after SSR to prevent host enter TX IBS_Sleep mode. Changes since v6-7: - Merge the changes into a single patch. - Update commit. Changes since v1-5: - Add an explanation for HCI_QUIRK_NON_PERSISTENT_SETUP. - Add commments for msleep(50). - Update format and commit. Signed-off-by: Shuai Zhang <quic_shuaz(a)quicinc.com> --- drivers/bluetooth/hci_qca.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 4e56782b0..9dc59b002 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1653,6 +1653,39 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code) skb_queue_purge(&qca->rx_memdump_q); } + /* + * If the BT chip's bt_en pin is connected to a 3.3V power supply via + * hardware and always stays high, driver cannot control the bt_en pin. + * As a result, during SSR (SubSystem Restart), QCA_SSR_TRIGGERED and + * QCA_IBS_DISABLED flags cannot be cleared, which leads to a reset + * command timeout. + * Add an msleep delay to ensure controller completes the SSR process. + * + * Host will not download the firmware after SSR, controller to remain + * in the IBS_WAKE state, and the host needs to synchronize with it + * + * Since the bluetooth chip has been reset, clear the memdump state. + */ + if (!test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) { + /* + * When the SSR (SubSystem Restart) duration exceeds 2 seconds, + * it triggers host tx_idle_delay, which sets host TX state + * to sleep. Reset tx_idle_timer after SSR to prevent + * host enter TX IBS_Sleep mode. + */ + mod_timer(&qca->tx_idle_timer, jiffies + + msecs_to_jiffies(qca->tx_idle_delay)); + + /* Controller reset completion time is 50ms */ + msleep(50); + + clear_bit(QCA_SSR_TRIGGERED, &qca->flags); + clear_bit(QCA_IBS_DISABLED, &qca->flags); + + qca->tx_ibs_state = HCI_IBS_TX_AWAKE; + qca->memdump_state = QCA_MEMDUMP_IDLE; + } + clear_bit(QCA_HW_ERROR_EVENT, &qca->flags); } -- 2.34.1

4 months

[PATCH v1] spi: microchip-core-qspi: stop checking viability of op->max_freq in supports_op callback

by Conor Dooley

From: Conor Dooley <conor.dooley(a)microchip.com> In commit 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem operation frequency switches") the logic for checking the viability of op->max_freq in mchp_coreqspi_setup_clock() was copied into mchp_coreqspi_supports_op(). Unfortunately, op->max_freq is not valid when this function is called during probe but is instead zero. Accordingly, baud_rate_val is calculated to be INT_MAX due to division by zero, causing probe of the attached memory device to fail. Seemingly spi-microchip-core-qspi was the only driver that had such a modification made to its supports_op callback when the per_op_freq capability was added, so just remove it to restore prior functionality. CC: stable(a)vger.kernel.org Reported-by: Valentina Fernandez <valentina.fernandezalanis(a)microchip.com> Fixes: 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem operation frequency switches") Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> --- CC: Conor Dooley <conor.dooley(a)microchip.com> CC: Daire McNamara <daire.mcnamara(a)microchip.com> CC: Mark Brown <broonie(a)kernel.org> CC: Miquel Raynal <miquel.raynal(a)bootlin.com> CC: linux-spi(a)vger.kernel.org CC: linux-kernel(a)vger.kernel.org --- drivers/spi/spi-microchip-core-qspi.c | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/drivers/spi/spi-microchip-core-qspi.c b/drivers/spi/spi-microchip-core-qspi.c index d13a9b755c7f8..8dc98b17f77b5 100644 --- a/drivers/spi/spi-microchip-core-qspi.c +++ b/drivers/spi/spi-microchip-core-qspi.c @@ -531,10 +531,6 @@ static int mchp_coreqspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *o static bool mchp_coreqspi_supports_op(struct spi_mem *mem, const struct spi_mem_op *op) { - struct mchp_coreqspi *qspi = spi_controller_get_devdata(mem->spi->controller); - unsigned long clk_hz; - u32 baud_rate_val; - if (!spi_mem_default_supports_op(mem, op)) return false; @@ -557,14 +553,6 @@ static bool mchp_coreqspi_supports_op(struct spi_mem *mem, const struct spi_mem_ return false; } - clk_hz = clk_get_rate(qspi->clk); - if (!clk_hz) - return false; - - baud_rate_val = DIV_ROUND_UP(clk_hz, 2 * op->max_freq); - if (baud_rate_val > MAX_DIVIDER || baud_rate_val < MIN_DIVIDER) - return false; - return true; } -- 2.47.2

4 months

[PATCH] PM: EM: Fix late boot with holes in CPU topology

by Christian Loehle

commit e3f1164fc9ee ("PM: EM: Support late CPUs booting and capacity adjustment") added a mechanism to handle CPUs that come up late by retrying when any of the `cpufreq_cpu_get()` call fails. However, if there are holes in the CPU topology (offline CPUs, e.g. nosmt), the first missing CPU causes the loop to break, preventing subsequent online CPUs from being updated. Instead of aborting on the first missing CPU policy, loop through all and retry if any were missing. Fixes: e3f1164fc9ee ("PM: EM: Support late CPUs booting and capacity adjustment") Suggested-by: Kenneth Crudup <kenneth.crudup(a)gmail.com> Reported-by: Kenneth Crudup <kenneth.crudup(a)gmail.com> Closes: https://lore.kernel.org/linux-pm/40212796-734c-4140-8a85-854f72b8144d@panix… Cc: stable(a)vger.kernel.org Signed-off-by: Christian Loehle <christian.loehle(a)arm.com> --- kernel/power/energy_model.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c index ea7995a25780..b63c2afc1379 100644 --- a/kernel/power/energy_model.c +++ b/kernel/power/energy_model.c @@ -778,7 +778,7 @@ void em_adjust_cpu_capacity(unsigned int cpu) static void em_check_capacity_update(void) { cpumask_var_t cpu_done_mask; - int cpu; + int cpu, failed_cpus = 0; if (!zalloc_cpumask_var(&cpu_done_mask, GFP_KERNEL)) { pr_warn("no free memory\n"); @@ -796,10 +796,8 @@ static void em_check_capacity_update(void) policy = cpufreq_cpu_get(cpu); if (!policy) { - pr_debug("Accessing cpu%d policy failed\n", cpu); - schedule_delayed_work(&em_update_work, - msecs_to_jiffies(1000)); - break; + failed_cpus++; + continue; } cpufreq_cpu_put(policy); @@ -814,6 +812,11 @@ static void em_check_capacity_update(void) em_adjust_new_capacity(cpu, dev, pd); } + if (failed_cpus) { + pr_debug("Accessing %d policies failed, retrying\n", failed_cpus); + schedule_delayed_work(&em_update_work, msecs_to_jiffies(1000)); + } + free_cpumask_var(cpu_done_mask); } -- 2.34.1

4 months

[PATCH v2] arm64: dts: qcom: sm8450: Fix address for usb controller node

by Krishna Kurapati

Correct the address in usb controller node to fix the following warning: Warning (simple_bus_reg): /soc@0/usb@a6f8800: simple-bus unit address format error, expected "a600000" Fixes: c5a87e3a6b3e ("arm64: dts: qcom: sm8450: Flatten usb controller node") Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202508121834.953Mvah2-lkp@intel.com/ Signed-off-by: Krishna Kurapati <krishna.kurapati(a)oss.qualcomm.com> --- This change was tested with W=1 and the reported issue is not seen. Also didn't add RB Tag received from Neil Armstrong since there is a change in commit text. This change is based on top of latest linux next. Changes in v2: Fixed the fixes tag. Link to v1: https://lore.kernel.org/all/20250813063840.2158792-1-krishna.kurapati@oss.q… arch/arm64/boot/dts/qcom/sm8450.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi index 2baef6869ed7..38c91c3ec787 100644 --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi @@ -5417,7 +5417,7 @@ opp-202000000 { }; }; - usb_1: usb@a6f8800 { + usb_1: usb@a600000 { compatible = "qcom,sm8450-dwc3", "qcom,snps-dwc3"; reg = <0 0x0a600000 0 0xfc100>; status = "disabled"; -- 2.34.1

4 months

[PATCH v3 0/2] i2c: pxa: fix I2C communication on Armada 3700

by Gabor Juhos

There is a long standing bug which causes I2C communication not to work on the Armada 3700 based boards. The first patch in the series fixes that regression. The second patch improves recovery to make it more robust which helps to avoid communication problems with certain SFP modules. Signed-off-by: Gabor Juhos <j4g8y7(a)gmail.com> --- Changes in v3: - rebase on tip of i2c/for-current - remove Imre's tag from the cover letter, and replace his SoB tag to Reviewed-by in the individual patches - rework the second patch so it does not need changes in the I2C core code, and drop the first one as it is not needed now - Link to v2: https://lore.kernel.org/r/20250811-i2c-pxa-fix-i2c-communication-v2-0-ca42e… Changes in v2: - collect offered tags - rebase and retest on tip of i2c/for-current - Link to v1: https://lore.kernel.org/r/20250511-i2c-pxa-fix-i2c-communication-v1-0-e9097… --- Gabor Juhos (2): i2c: pxa: defer reset on Armada 3700 when recovery is used i2c: pxa: handle 'Early Bus Busy' condition on Armada 3700 drivers/i2c/busses/i2c-pxa.c | 35 ++++++++++++++++++++++++++++------- 1 file changed, 28 insertions(+), 7 deletions(-) --- base-commit: 3dd22078026c7cad4d4a3f32c5dc5452c7180de8 change-id: 20250510-i2c-pxa-fix-i2c-communication-3e6de1e3d0c6 Best regards, -- Gabor Juhos <j4g8y7(a)gmail.com>

4 months

5.10 backport request: ASoC: Intel: sof_rt5682: shrink platform_id names below 20 characters

by Michał Górny

Hello, I would like to request backporting the following patch to 5.10 series: 590cfb082837cc6c0c595adf1711330197c86a58 ASoC: Intel: sof_rt5682: shrink platform_id names below 20 characters The patch seems to be already present in 5.15 and newer branches, and its lack seems to be causing out-of-bounds read. I've hit it in the wild while trying to install 5.10.241 on i686: sh /var/tmp/portage/sys-kernel/gentoo-kernel-5.10.241/work/linux-5.10/scripts/depmod.sh depmod 5.10.241-gentoo-dist depmod: FATAL: Module index: bad character '�'=0x80 - only 7-bit ASCII is supported: platform:jsl_rt5682_max98360ax� TIA. -- Best regards, Michał Górny

4 months

[PATCH v4 2/4] x86/cpu/topology: Always try cpu_parse_topology_ext() on AMD/Hygon

by K Prateek Nayak

Support for parsing the topology on AMD/Hygon processors using CPUID leaf 0xb was added in commit 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available"). In an effort to keep all the topology parsing bits in one place, this commit also introduced a pseudo dependency on the TOPOEXT feature to parse the CPUID leaf 0xb. TOPOEXT feature (CPUID 0x80000001 ECX[22]) advertises the support for Cache Properties leaf 0x8000001d and the CPUID leaf 0x8000001e EAX for "Extended APIC ID" however support for 0xb was introduced alongside the x2APIC support not only on AMD [1], but also historically on x86 [2]. Similar to 0xb, the support for extended CPU topology leaf 0x80000026 too does not depend on the TOPOEXT feature. The support for these leaves is expected to be confirmed by ensuring "leaf <= {extended_}cpuid_level" and then parsing the level 0 of the respective leaf to confirm EBX[15:0] (LogProcAtThisLevel) is non-zero as stated in the definition of "CPUID_Fn0000000B_EAX_x00 [Extended Topology Enumeration] (Core::X86::Cpuid::ExtTopEnumEax0)" in Processor Programming Reference (PPR) for AMD Family 19h Model 01h Rev B1 Vol1 [3] Sec. 2.1.15.1 "CPUID Instruction Functions". This has not been a problem on baremetal platforms since support for TOPOEXT (Fam 0x15 and later) predates the support for CPUID leaf 0xb (Fam 0x17[Zen2] and later), however, for AMD guests on QEMU, "x2apic" feature can be enabled independent of the "topoext" feature where QEMU expects topology and the initial APICID to be parsed using the CPUID leaf 0xb (especially when number of cores > 255) which is populated independent of the "topoext" feature flag. Unconditionally call cpu_parse_topology_ext() on AMD and Hygon processors to first parse the topology using the XTOPOLOGY leaves (0x80000026 / 0xb) before using the TOPOEXT leaf (0x8000001e). Cc: stable(a)vger.kernel.org # Only v6.9 and above Link: https://lore.kernel.org/lkml/1529686927-7665-1-git-send-email-suravee.suthi… [1] Link: https://lore.kernel.org/lkml/20080818181435.523309000@linux-os.sc.intel.com/ [2] Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 [3] Suggested-by: Naveen N Rao (AMD) <naveen(a)kernel.org> Fixes: 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available") Signed-off-by: K Prateek Nayak <kprateek.nayak(a)amd.com> --- Changelog v3..v4: o Quoted relevant section of the PPR justifying the changes. o Moved this patch up ahead. o Cc'd stable and made a note that backports should target v6.9 and above since this depends on the x86 topology rewrite. --- arch/x86/kernel/cpu/topology_amd.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c index 827dd0dbb6e9..4e3134a5550c 100644 --- a/arch/x86/kernel/cpu/topology_amd.c +++ b/arch/x86/kernel/cpu/topology_amd.c @@ -175,18 +175,14 @@ static void topoext_fixup(struct topo_scan *tscan) static void parse_topology_amd(struct topo_scan *tscan) { - bool has_topoext = false; - /* - * If the extended topology leaf 0x8000_001e is available - * try to get SMT, CORE, TILE, and DIE shifts from extended + * Try to get SMT, CORE, TILE, and DIE shifts from extended * CPUID leaf 0x8000_0026 on supported processors first. If * extended CPUID leaf 0x8000_0026 is not supported, try to * get SMT and CORE shift from leaf 0xb first, then try to * get the CORE shift from leaf 0x8000_0008. */ - if (cpu_feature_enabled(X86_FEATURE_TOPOEXT)) - has_topoext = cpu_parse_topology_ext(tscan); + bool has_topoext = cpu_parse_topology_ext(tscan); if (cpu_feature_enabled(X86_FEATURE_AMD_HTR_CORES)) tscan->c->topo.cpu_type = cpuid_ebx(0x80000026); -- 2.34.1

4 months

[PATCH v2] mtd: nand: raw: atmel: Respect tAR, tCLR in read setup timing

by A. Sverdlin

From: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> Having setup time 0 violates tAR, tCLR of some chips, for instance TOSHIBA TC58NVG2S3ETAI0 cannot be detected successfully (first ID byte being read duplicated, i.e. 98 98 dc 90 15 76 14 03 instead of 98 dc 90 15 76 ...). Atmel Application Notes postulated 1 cycle NRD_SETUP without explanation [1], but it looks more appropriate to just calculate setup time properly. [1] Link: https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/Applicatio… Cc: stable(a)vger.kernel.org Fixes: f9ce2eddf176 ("mtd: nand: atmel: Add ->setup_data_interface() hooks") Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> --- v2: - Cc'ed stable - reformatted atmel_smc_cs_conf_set_setup() call - rebased onto mtd/fixes drivers/mtd/nand/raw/atmel/nand-controller.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c index dedcca87defc7..ad0eff385e123 100644 --- a/drivers/mtd/nand/raw/atmel/nand-controller.c +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c @@ -1377,14 +1377,24 @@ static int atmel_smc_nand_prepare_smcconf(struct atmel_nand *nand, if (ret) return ret; + /* + * Read setup timing depends on the operation done on the NAND: + * + * NRD_SETUP = max(tAR, tCLR) + */ + timeps = max(conf->timings.sdr.tAR_min, conf->timings.sdr.tCLR_min); + ncycles = DIV_ROUND_UP(timeps, mckperiodps); + totalcycles += ncycles; + ret = atmel_smc_cs_conf_set_setup(smcconf, ATMEL_SMC_NRD_SHIFT, ncycles); + if (ret) + return ret; + /* * The read cycle timing is directly matching tRC, but is also * dependent on the setup and hold timings we calculated earlier, * which gives: * - * NRD_CYCLE = max(tRC, NRD_PULSE + NRD_HOLD) - * - * NRD_SETUP is always 0. + * NRD_CYCLE = max(tRC, NRD_SETUP + NRD_PULSE + NRD_HOLD) */ ncycles = DIV_ROUND_UP(conf->timings.sdr.tRC_min, mckperiodps); ncycles = max(totalcycles, ncycles); -- 2.50.1

4 months

[PATCH] mtd: rawnand: stm32_fmc2: fix ECC overwrite

by Christophe Kerello

In case OOB write is requested during a data write, ECC is currently lost. Avoid this issue by only writing in the free spare area. This issue has been seen with a YAFFS2 file system. Signed-off-by: Christophe Kerello <christophe.kerello(a)foss.st.com> Cc: stable(a)vger.kernel.org Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver") --- drivers/mtd/nand/raw/stm32_fmc2_nand.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c index a960403081f11091837b73b8610231fe421d0c05..f84f23392fa441327bec90ba12a2a57d825d9330 100644 --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c @@ -996,9 +996,21 @@ static int stm32_fmc2_nfc_seq_write(struct nand_chip *chip, const u8 *buf, /* Write oob */ if (oob_required) { - ret = nand_change_write_column_op(chip, mtd->writesize, - chip->oob_poi, mtd->oobsize, - false); + unsigned int offset_in_page = mtd->writesize; + const void *buf = chip->oob_poi; + unsigned int len = mtd->oobsize; + + if (!raw) { + struct mtd_oob_region oob_free; + + mtd_ooblayout_free(mtd, 0, &oob_free); + offset_in_page += oob_free.offset; + buf += oob_free.offset; + len = oob_free.length; + } + + ret = nand_change_write_column_op(chip, offset_in_page, + buf, len, false); if (ret) return ret; } --- base-commit: fb2fae70e7e985c4acb1ad96110d8b98bb64a87c change-id: 20250811-fix-ecc-overwrite-9962b7797746 Best regards, -- Christophe Kerello <christophe.kerello(a)foss.st.com>

4 months

[PATCH] mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer

by Christophe Kerello

Avoid below overlapping mappings by using a contiguous non-cacheable buffer. [ 4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST, overlapping mappings aren't supported [ 4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300 [ 4.097071] Modules linked in: [ 4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1 [ 4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT) [ 4.118824] Workqueue: events_unbound deferred_probe_work_func [ 4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.131624] pc : add_dma_entry+0x23c/0x300 [ 4.135658] lr : add_dma_entry+0x23c/0x300 [ 4.139792] sp : ffff800009dbb490 [ 4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000 [ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8 [ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20 [ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006 [ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e [ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec [ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58 [ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000 [ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40 [ 4.214185] Call trace: [ 4.216605] add_dma_entry+0x23c/0x300 [ 4.220338] debug_dma_map_sg+0x198/0x350 [ 4.224373] __dma_map_sg_attrs+0xa0/0x110 [ 4.228411] dma_map_sg_attrs+0x10/0x2c [ 4.232247] stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc [ 4.237088] stm32_fmc2_nfc_seq_read_page+0xc8/0x174 [ 4.242127] nand_read_oob+0x1d4/0x8e0 [ 4.245861] mtd_read_oob_std+0x58/0x84 [ 4.249596] mtd_read_oob+0x90/0x150 [ 4.253231] mtd_read+0x68/0xac Signed-off-by: Christophe Kerello <christophe.kerello(a)foss.st.com> Cc: stable(a)vger.kernel.org Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver") --- drivers/mtd/nand/raw/stm32_fmc2_nand.c | 28 +++++++++------------------- 1 file changed, 9 insertions(+), 19 deletions(-) diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c index a960403081f11091837b73b8610231fe421d0c05..222c3c3b684841879a55835e802dcf9983860c28 100644 --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c @@ -272,6 +272,7 @@ struct stm32_fmc2_nfc { struct sg_table dma_data_sg; struct sg_table dma_ecc_sg; u8 *ecc_buf; + dma_addr_t dma_ecc_addr; int dma_ecc_len; u32 tx_dma_max_burst; u32 rx_dma_max_burst; @@ -902,17 +903,10 @@ static int stm32_fmc2_nfc_xfer(struct nand_chip *chip, const u8 *buf, if (!write_data && !raw) { /* Configure DMA ECC status */ - p = nfc->ecc_buf; for_each_sg(nfc->dma_ecc_sg.sgl, sg, eccsteps, s) { - sg_set_buf(sg, p, nfc->dma_ecc_len); - p += nfc->dma_ecc_len; - } - - ret = dma_map_sg(nfc->dev, nfc->dma_ecc_sg.sgl, - eccsteps, dma_data_dir); - if (!ret) { - ret = -EIO; - goto err_unmap_data; + sg_dma_address(sg) = nfc->dma_ecc_addr + + s * nfc->dma_ecc_len; + sg_dma_len(sg) = nfc->dma_ecc_len; } desc_ecc = dmaengine_prep_slave_sg(nfc->dma_ecc_ch, @@ -921,7 +915,7 @@ static int stm32_fmc2_nfc_xfer(struct nand_chip *chip, const u8 *buf, DMA_PREP_INTERRUPT); if (!desc_ecc) { ret = -ENOMEM; - goto err_unmap_ecc; + goto err_unmap_data; } reinit_completion(&nfc->dma_ecc_complete); @@ -929,7 +923,7 @@ static int stm32_fmc2_nfc_xfer(struct nand_chip *chip, const u8 *buf, desc_ecc->callback_param = &nfc->dma_ecc_complete; ret = dma_submit_error(dmaengine_submit(desc_ecc)); if (ret) - goto err_unmap_ecc; + goto err_unmap_data; dma_async_issue_pending(nfc->dma_ecc_ch); } @@ -949,7 +943,7 @@ static int stm32_fmc2_nfc_xfer(struct nand_chip *chip, const u8 *buf, if (!write_data && !raw) dmaengine_terminate_all(nfc->dma_ecc_ch); ret = -ETIMEDOUT; - goto err_unmap_ecc; + goto err_unmap_data; } /* Wait DMA data transfer completion */ @@ -969,11 +963,6 @@ static int stm32_fmc2_nfc_xfer(struct nand_chip *chip, const u8 *buf, } } -err_unmap_ecc: - if (!write_data && !raw) - dma_unmap_sg(nfc->dev, nfc->dma_ecc_sg.sgl, - eccsteps, dma_data_dir); - err_unmap_data: dma_unmap_sg(nfc->dev, nfc->dma_data_sg.sgl, eccsteps, dma_data_dir); @@ -1610,7 +1599,8 @@ static int stm32_fmc2_nfc_dma_setup(struct stm32_fmc2_nfc *nfc) return ret; /* Allocate a buffer to store ECC status registers */ - nfc->ecc_buf = devm_kzalloc(nfc->dev, FMC2_MAX_ECC_BUF_LEN, GFP_KERNEL); + nfc->ecc_buf = dmam_alloc_coherent(nfc->dev, FMC2_MAX_ECC_BUF_LEN, + &nfc->dma_ecc_addr, GFP_KERNEL); if (!nfc->ecc_buf) return -ENOMEM; --- base-commit: fb2fae70e7e985c4acb1ad96110d8b98bb64a87c change-id: 20250811-fix-dma-overlapping-1c8fba7fd519 Best regards, -- Christophe Kerello <christophe.kerello(a)foss.st.com>

4 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2025