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

[PATCH v2 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

Changes in v2:
 - Fix $id in dt-binding
 - Use pm_ptr() instead of pm_sleep_ptr()
 - Link to v1: https://lore.kernel.org/linux-devicetree/20260629065517.868418-1-s-k6@ti.com/

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

[PATCH v2 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..5a5cac92082b
--- /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/memory-controllers/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: [PATCH v2 1/2] dt-bindings: memory: Add TI FSS_FSAS binding

[Rob Herring (Arm)]

On Mon, 29 Jun 2026 12:50:54 +0530, Santhosh Kumar K wrote:
> 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
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

[PATCH v2 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..a5f42afc694c
--- /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_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: [PATCH v2 2/2] memory: ti-k3-fsas: Add TI FSS_FSAS driver

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Missing PM Runtime integration causes bus faults and silent state loss.
- [Critical] Lack of probe ordering guarantees between the FSAS wrapper and the OSPI driver risks DMA corruption.
--

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

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

This patch adds a platform driver for the TI Flash SubSystem Application
Subsystem in K3 SoCs. It configures the SYSCONFIG register to disable OSPI
XIP prefetch, preventing DMA data corruption.

> diff --git a/drivers/memory/ti-k3-fsas.c b/drivers/memory/ti-k3-fsas.c
> new file mode 100644
> index 0000000000000..a5f42afc694c5
> --- /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: Critical]
Is it possible for the device to be unpowered when accessing the registers
here? 

Accessing fsas->base without first calling pm_runtime_enable() and
pm_runtime_get_sync() could cause a synchronous external abort on K3 SoCs.

[Severity: Critical]
Is there anything guaranteeing this probe finishes before the main OSPI
controller probes?

If the OSPI driver (cadence-quadspi) probes and initiates DMA transfers
before this independent platform driver runs, the transfers could occur with
XIP prefetch enabled, corrupting the data.

> +
> +	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);

[Severity: Critical]
Will the hardware state be lost during runtime suspend?

By using DEFINE_SIMPLE_DEV_PM_OPS without runtime PM callbacks, if the
domain goes into runtime suspend (e.g. when the OSPI controller is idle),
the hardware state could reset. 

Because there are no runtime_resume callbacks, the FSAS_SYSCONFIG_DISXIP
bit will remain lost. The OSPI controller could then perform subsequent DMA
transfers with XIP prefetch enabled, causing silent data corruption.

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

Re: [PATCH v2 0/2] Fix OSPI DMA corruption via FSS_FSAS driver

[Krzysztof Kozlowski]

On Mon, Jun 29, 2026 at 12:50:53PM +0530, Santhosh Kumar K wrote:
> 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

Three versions within one day that's way too much. And b4 diff does not
work:

b4 diff 20260629072055.896322-1-s-k6@ti.com
Looking up https://lore.kernel.org/all/20260629072055.896322-1-s-k6@ti.com/
Grabbing thread from lore.kernel.org/all/20260629072055.896322-1-s-k6@ti.com/t.mbox.gz
Checking for older revisions
Grabbing search results from lore.kernel.org
  Added from v1: 6 patches
---
Analyzing 14 messages in the thread
WARNING: duplicate messages found at index 2
   Subject 1: memory: ti-k3-fsas: Add TI FSS_FSAS driver
   Subject 2: memory: ti-k3-fsas: Add TI FSS_FSAS driver
  2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
   Subject 1: dt-bindings: memory: Add TI FSS_FSAS binding
   Subject 2: dt-bindings: memory: Add TI FSS_FSAS binding
  2 is not a reply... assume additional patch
Preparing fake-am for v1: dt-bindings: memory: Add TI FSS_FSAS binding
ERROR: v1 series incomplete; unable to create a fake-am range

If you want to make it difficult for maintainer to review, your patches
will be moved to the end of the queue.

Best regards,
Krzysztof