Re: [PATCH v2 3/3] nvmem: uniphier-efuse: Add ti,am62p-efuse compatible

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Architectural coupling of unrelated vendor platforms by hijacking the Socionext Uniphier driver for a TI AM62p device, and potential synchronous external abort due to unaligned MMIO access.
--

commit 72b4a8c2f112a40ac42acd9e0e7de236103e4616
Author: Judith Mendez <jm@ti.com>
Subject: nvmem: uniphier-efuse: Add ti,am62p-efuse compatible

This commit adds the "ti,am62p-efuse" compatible string to the
uniphier-efuse driver. It leverages this nvmem provider to read
silicon revision information for the AM62p device.

> diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c
> index 6ad3295d31951..35977e1864135 100644
> --- a/drivers/nvmem/uniphier-efuse.c
> +++ b/drivers/nvmem/uniphier-efuse.c
> @@ -60,6 +60,7 @@ static int uniphier_efuse_probe(struct platform_device *pdev)
>  
>  static const struct of_device_id uniphier_efuse_of_match[] = {
>  	{ .compatible = "socionext,uniphier-efuse",},
> +	{ .compatible = "ti,am62p-efuse",},

[Severity: Medium]
Does adding a TI K3 compatible string to the Socionext Uniphier driver create
an architectural coupling between unrelated vendor platforms?

This forces TI hardware to depend on a Socionext driver. If Socionext
maintainers add vendor-specific quirks in the future, it might break TI
devices.

Also, the Uniphier driver accesses MMIO using readb() in uniphier_reg_read().
Could this trigger a synchronous external abort on the AM62p? TI K3
interconnects frequently enforce strict 32-bit access requirements.
Performing byte-level accesses on these MMIO regions might lead to bus errors
during device probe at early boot.

>  	{/* sentinel */},
>  };
>  MODULE_DEVICE_TABLE(of, uniphier_efuse_of_match);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902222759.736124-1-jm@ti.com?part=3