Re: [PATCH v3 3/3] nvmem: uniphier-efuse: Add ti,am62p-efuse compatible
From: sashiko-bot@kernel.org
Date: 2026-09-10 16:04:22
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] Inappropriate reuse of a vendor-specific driver and redundant OF match entry for TI AM62p -- commit 614c65812039ca53f1d8ede20ca79f433983e7a7 Author: Judith Mendez [off-list ref] nvmem: uniphier-efuse: Add ti,am62p-efuse compatible This commit adds the ti,am62p-efuse compatible string to the uniphier-efuse driver to supply silicon revision information for AM62p devices.
quoted hunk ↗ jump to hunk
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: Low] Is this explicit match entry redundant? The DT bindings require socionext,uniphier-efuse as a fallback for ti,am62p-efuse. Because of this mandatory fallback, the Linux OF matching algorithm will already match the device using the existing entry without needing the TI compatible string in uniphier_efuse_of_match. Also, does piggybacking onto another vendor's driver create confusing Kconfig dependencies? TI platforms would now need to enable NVMEM_UNIPHIER_EFUSE (prompted as UniPhier SoCs eFuse support), which couples their maintenance and could be problematic if either vendor IP diverges in the future.
{/* sentinel */},
};-- Sashiko AI review · https://sashiko.dev/#/patchset/20260910155509.1425682-1-jm@ti.com?part=3