[RESEND PATCH 0/2] Fix OSPI DMA corruption via FSS_FSAS driver

[RESEND PATCH 0/2] Fix OSPI DMA corruption via FSS_FSAS driver

[Santhosh Kumar K]

On TI K3 SoCs, DMA transfers from OSPI produce corrupted data when the
source address is only 4-byte aligned (not 4K-aligned). The root cause
is XIP read prefetch in the FSS_FSAS_GENREGS wrapper (SYSCONFIG.DISXIP,
bit 7), which is enabled by default.

This series adds a dedicated FSS_FSAS platform driver that disables XIP
prefetch at probe, plus the respective DT binding.

Testing:
This series was tested on TI's
AM62Ax SK with OSPI NAND flash and
AM62Px SK with OSPI NOR flash:

Test log: https://gist.github.com/santhosh21/3ac2a0273065e86315a9b442327c9599
Repo: https://github.com/santhosh21/linux/commits/fsas

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>

Santhosh Kumar K (2):
  dt-bindings: memory: Add TI FSS_FSAS binding
  memory: ti-k3-fsas: Add TI FSS_FSAS driver

 .../memory-controllers/ti,am62a-fsas.yaml     | 39 ++++++++++
 drivers/memory/Kconfig                        | 10 +++
 drivers/memory/Makefile                       |  1 +
 drivers/memory/ti-k3-fsas.c                   | 74 +++++++++++++++++++
 4 files changed, 124 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti,am62a-fsas.yaml
 create mode 100644 drivers/memory/ti-k3-fsas.c

-- 
2.34.1

[RESEND PATCH 1/2] dt-bindings: memory: Add TI FSS_FSAS binding

[Santhosh Kumar K]

Add DT binding for the TI Flash Subsystem Application Subsystem
(FSS_FSAS_GENREGS) wrapper present in TI K3 SoCs. This block controls
XIP read prefetch for the OSPI controller.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
---
 .../memory-controllers/ti,am62a-fsas.yaml     | 39 +++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti,am62a-fsas.yaml

diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,am62a-fsas.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,am62a-fsas.yaml
new file mode 100644
index 000000000000..81c71ebfb7e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti,am62a-fsas.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2025 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/ti,am62a-fsas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 Flash SubSystem Application Subsystem (FSS_FSAS)
+
+maintainers:
+  - Santhosh Kumar K <s-k6@ti.com>
+
+description:
+  The FSS_FSAS_GENREGS block is a TI wrapper inside the Flash SubSystem (FSS).
+
+properties:
+  compatible:
+    const: ti,am62a-fsas
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    bus {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        fsas@fc10000 {
+            compatible = "ti,am62a-fsas";
+            reg = <0x00 0x0fc10000 0x00 0x100>;
+        };
+    };
-- 
2.34.1

Re: [RESEND PATCH 1/2] dt-bindings: memory: Add TI FSS_FSAS binding

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `$id` field in the YAML binding does not match the file's path relative to `Documentation/devicetree/bindings/`.
--

commit e6d297ef6febec50bca3376d0c0b57a9ece18a98
Author: Santhosh Kumar K <s-k6@ti.com>

dt-bindings: memory: Add TI FSS_FSAS binding

Add DT binding for the TI Flash Subsystem Application Subsystem
(FSS_FSAS_GENREGS) wrapper present in TI K3 SoCs. This block controls
XIP read prefetch for the OSPI controller.

> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,am62a-fsas.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,am62a-fsas.yaml
> new file mode 100644
> index 0000000000000..81c71ebfb7e13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/ti,am62a-fsas.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2025 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/ti/ti,am62a-fsas.yaml#

[Severity: Low]
Does this $id field path match the actual file location? 

The schema specifies the path as soc/ti/ti,am62a-fsas.yaml, but the patch
places the new file in memory-controllers/. Mismatched paths can break the
schema cross-reference system and cause dt_binding_check to report
misleading errors or silently skip validation.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629065517.868418-1-s-k6@ti.com?part=1

[RESEND PATCH 2/2] memory: ti-k3-fsas: Add TI FSS_FSAS driver

[Santhosh Kumar K]

Add a platform driver for the TI Flash SubSystem Application Subsystem
(FSS_FSAS_GENREGS) in K3 SoCs. This driver takes care of disabling the
OSPI XIP prefetch which causes DMA transfer data corruption.

Set SYSCONFIG.DISXIP to disable XIP read prefetch, preventing DMA data
corruption when the OSPI DMA source address is not 4K-aligned.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
---
 drivers/memory/Kconfig      | 10 +++++
 drivers/memory/Makefile     |  1 +
 drivers/memory/ti-k3-fsas.c | 74 +++++++++++++++++++++++++++++++++++++
 3 files changed, 85 insertions(+)
 create mode 100644 drivers/memory/ti-k3-fsas.c

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index e5527020ff33..954e47810e8d 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -125,6 +125,16 @@ config TI_EMIF_SRAM
 	  sequence so this driver provides several relocatable PM functions
 	  for the SoC PM code to use.
 
+config TI_K3_FSS_FSAS
+	tristate "TI K3 Flash Subsystem Application Subsystem (FSAS) support"
+	depends on ARCH_K3 || COMPILE_TEST
+	help
+	  Driver for the TI K3 Flash Subsystem Application Subsystem
+	  (FSS_FSAS_GENREGS) wrapper found on K3 related SoCs.
+
+	  This driver takes care of disabling the OSPI XIP prefetch which
+	  causes DMA transfer data corruption.
+
 config FPGA_DFL_EMIF
 	tristate "FPGA DFL EMIF Driver"
 	depends on FPGA_DFL && HAS_IOMEM
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 3ee883c8759a..8dc4860f615d 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_STM32_OMM)		+= stm32_omm.o
 obj-$(CONFIG_SAMSUNG_MC)	+= samsung/
 obj-$(CONFIG_TEGRA_MC)		+= tegra/
 obj-$(CONFIG_TI_EMIF_SRAM)	+= ti-emif-sram.o
+obj-$(CONFIG_TI_K3_FSS_FSAS)	+= ti-k3-fsas.o
 obj-$(CONFIG_FPGA_DFL_EMIF)	+= dfl-emif.o
 
 ti-emif-sram-objs		:= ti-emif-pm.o ti-emif-sram-pm.o
diff --git a/drivers/memory/ti-k3-fsas.c b/drivers/memory/ti-k3-fsas.c
new file mode 100644
index 000000000000..9ff109b8d96f
--- /dev/null
+++ b/drivers/memory/ti-k3-fsas.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI K3 Flash Subsystem Application Subsystem (FSS_FSAS) driver
+ *
+ * Copyright (C) 2025 Texas Instruments Incorporated - https://www.ti.com
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm.h>
+
+#define FSAS_GENREGS_SYSCONFIG 0x04
+#define FSAS_SYSCONFIG_DISXIP BIT(7)
+
+struct k3_fsas {
+	void __iomem *base;
+};
+
+static void k3_fsas_disable_xip_prefetch(struct k3_fsas *fsas)
+{
+	u32 val;
+
+	val = readl(fsas->base + FSAS_GENREGS_SYSCONFIG);
+	val |= FSAS_SYSCONFIG_DISXIP;
+	writel(val, fsas->base + FSAS_GENREGS_SYSCONFIG);
+}
+
+static int k3_fsas_probe(struct platform_device *pdev)
+{
+	struct k3_fsas *fsas;
+
+	fsas = devm_kzalloc(&pdev->dev, sizeof(*fsas), GFP_KERNEL);
+	if (!fsas)
+		return -ENOMEM;
+
+	fsas->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(fsas->base))
+		return PTR_ERR(fsas->base);
+
+	platform_set_drvdata(pdev, fsas);
+
+	k3_fsas_disable_xip_prefetch(fsas);
+
+	return 0;
+}
+
+static int k3_fsas_resume(struct device *dev)
+{
+	k3_fsas_disable_xip_prefetch(dev_get_drvdata(dev));
+	return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(k3_fsas_pm_ops, NULL, k3_fsas_resume);
+
+static const struct of_device_id k3_fsas_of_match[] = {
+	{ .compatible = "ti,am62a-fsas" },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, k3_fsas_of_match);
+
+static struct platform_driver k3_fsas_driver = {
+	.probe = k3_fsas_probe,
+	.driver = {
+		.name		= "k3-fsas",
+		.of_match_table	= k3_fsas_of_match,
+		.pm		= pm_sleep_ptr(&k3_fsas_pm_ops),
+	},
+};
+module_platform_driver(k3_fsas_driver);
+
+MODULE_DESCRIPTION("TI K3 Flash SubSystem Application Subsystem driver");
+MODULE_LICENSE("GPL");
-- 
2.34.1

Re: [RESEND PATCH 2/2] memory: ti-k3-fsas: Add TI FSS_FSAS driver

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The driver accesses memory-mapped registers without enabling the device's power domain via runtime PM, causing a synchronous external abort.
- [High] Probe ordering race condition between the FSS wrapper and the OSPI child device can lead to DMA data corruption.
- [Low] The TI_K3_FSS_FSAS driver can be built on architectures without HAS_IOMEM via COMPILE_TEST, causing build failures.
--

commit 472a60060ef7ef11966794e0d895b41600560dca
Author: Santhosh Kumar K <s-k6@ti.com>

memory: ti-k3-fsas: Add TI FSS_FSAS driver

Add a platform driver for the TI Flash SubSystem Application Subsystem
(FSS_FSAS_GENREGS) in K3 SoCs. This driver takes care of disabling the
OSPI XIP prefetch which causes DMA transfer data corruption.

> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index e5527020ff337..954e47810e8db 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -125,6 +125,16 @@ config TI_EMIF_SRAM
>  	  sequence so this driver provides several relocatable PM functions
>  	  for the SoC PM code to use.
>  
> +config TI_K3_FSS_FSAS
> +	tristate "TI K3 Flash Subsystem Application Subsystem (FSAS) support"
> +	depends on ARCH_K3 || COMPILE_TEST

[Severity: Low]
Does this config need to depend on HAS_IOMEM?

If COMPILE_TEST is enabled on architectures that do not support MMIO and do
not select HAS_IOMEM (e.g., s390 or UM), will compiling this driver fail
because devm_platform_ioremap_resource(), readl(), and writel() are not fully
supported?

> +	help
> +	  Driver for the TI K3 Flash Subsystem Application Subsystem
> +	  (FSS_FSAS_GENREGS) wrapper found on K3 related SoCs.

[ ... ]

> diff --git a/drivers/memory/ti-k3-fsas.c b/drivers/memory/ti-k3-fsas.c
> new file mode 100644
> index 0000000000000..9ff109b8d96fd
> --- /dev/null
> +++ b/drivers/memory/ti-k3-fsas.c

[ ... ]

> +static int k3_fsas_probe(struct platform_device *pdev)
> +{
> +	struct k3_fsas *fsas;
> +
> +	fsas = devm_kzalloc(&pdev->dev, sizeof(*fsas), GFP_KERNEL);
> +	if (!fsas)
> +		return -ENOMEM;
> +
> +	fsas->base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(fsas->base))
> +		return PTR_ERR(fsas->base);
> +
> +	platform_set_drvdata(pdev, fsas);
> +
> +	k3_fsas_disable_xip_prefetch(fsas);

[Severity: High]
Will this register access cause a synchronous external abort (bus fault) by
accessing memory-mapped registers before the device's power domain is enabled?

On TI K3 platforms, power domains and clocks are managed by the
ti_sci_pm_domain driver, and the hardware domain remains power-gated until
explicitly enabled.

Should this driver call pm_runtime_enable() and pm_runtime_resume_and_get()
before calling k3_fsas_disable_xip_prefetch()?

> +
> +	return 0;
> +}

[Severity: High]
Does this driver need to explicitly populate its child nodes using
devm_of_platform_populate() to prevent a probe ordering race with the OSPI
child device?

Since the driver core allows a child device to probe even if its parent device
is not yet bound, could the spi-cadence-quadspi driver probe first due to
module load ordering?

If the child initiates DMA transfers before this wrapper has probed and
disabled the prefetch, wouldn't it trigger the exact data corruption this
patch aims to fix?

> +
> +static int k3_fsas_resume(struct device *dev)
> +{
> +	k3_fsas_disable_xip_prefetch(dev_get_drvdata(dev));

[Severity: High]
Will this register access crash the system during resume?

Since this driver acts as a parent to the OSPI child device, it resumes before
the child. If the shared hardware power domain is completely powered off
at this point, accessing FSAS_GENREGS_SYSCONFIG here would cause a bus fault.

> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629065517.868418-1-s-k6@ti.com?part=2