Re: [PATCH v2 1/3] dt-bindings: nvmem: uniphier-efuse: Add ti,am62p-efuse compatible
From: sashiko-bot@kernel.org
Date: 2026-09-02 22:34:56
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] The Device Tree binding groups an unrelated Texas Instruments compatible string (`ti,am62p-efuse`) into the Socionext Uniphier eFuse schema strictly to reuse a Linux driver, violating the rule that DT bindings must describe hardware. -- commit bf8e60a2409a1898bd121ebca26b279cdf4f85e7 Author: Judith Mendez [off-list ref] dt-bindings: nvmem: uniphier-efuse: Add ti,am62p-efuse compatible This commit adds the ti,am62p-efuse compatible string to the Socionext Uniphier eFuse binding. The commit message notes this is done so the existing uniphier-efuse Linux driver can be used to read AM62P efuse registers for silicon revision detection.
quoted hunk ↗ jump to hunk
diff --git a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml index e27cbae2d63a0..5e1b90fc1ae45 100644 --- a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml +++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml@@ -16,7 +16,9 @@ allOf: properties: compatible: - const: socionext,uniphier-efuse + enum: + - socionext,uniphier-efuse + - ti,am62p-efuse
[Severity: Low] Does grouping an unrelated Texas Instruments compatible string into a Socionext binding conflict with the rule that Device Tree schemas must describe hardware blocks rather than software driver mappings? Grouping hardware from different vendors strictly to reuse a Linux driver creates an inaccurate hardware description. -- Sashiko AI review · https://sashiko.dev/#/patchset/20260902222759.736124-1-jm@ti.com?part=1