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

[sashiko-bot@kernel.org]

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