This series adds support for reading AM62P silicon revision from the
efuse GP_SW register. The solution reuses the  existing uniphier-efuse
driver by adding ti,am62p-efuse as a compatible string. The three patches
update the devicetree binding to document the new compatible, configure
the driver as mandatory builtin for K3 architectures, and extend the driver
to support AM62P devices. The uniphier-efuse driver is simple enough to be
reused for efuse register reads on the AM62P SoC.

Feedback is welcome on whether reusing the uniphier-efuse driver is the
preferred solution or if a dedicated AM62P efuse driver would be more
appropriate.

Patches have been tested on AM62p SK hardware using SR1.0, SR1.1 and SR1.2
silicon.

Judith Mendez (3):
  dt-bindings: nvmem: uniphier-efuse: Add ti,am62p-efuse compatible
  nvmem: uniphier-efuse: Enable for K3 SoCs
  nvmem: uniphier-efuse: Add ti,am62p-efuse compatible

 .../devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml   | 4 +++-
 drivers/nvmem/Kconfig                                         | 3 ++-
 drivers/nvmem/uniphier-efuse.c                                | 1 +
 3 files changed, 6 insertions(+), 2 deletions(-)

-- 
2.54.0

Hi Judith,

Sorry for late.

On 2026/08/13 0:44, Judith Mendez wrote:
> This series adds support for reading AM62P silicon revision from the
> efuse GP_SW register. The solution reuses the  existing uniphier-efuse
> driver by adding ti,am62p-efuse as a compatible string. The three patches
> update the devicetree binding to document the new compatible, configure
> the driver as mandatory builtin for K3 architectures, and extend the
> driver
> to support AM62P devices. The uniphier-efuse driver is simple enough to be
> reused for efuse register reads on the AM62P SoC.

Reusing the uniphier-efuse driver seems reasonable to me.

The driver is already fairly generic, and contains no arch-specific elements
that would justify introducing a dedicated driver at this point.

> Feedback is welcome on whether reusing the uniphier-efuse driver is the
> preferred solution or if a dedicated AM62P efuse driver would be more
> appropriate.
> 
> Patches have been tested on AM62p SK hardware using SR1.0, SR1.1 and SR1.2
> silicon.

Provided the functionality has been validated on the target hardware,
I would prefer to reuse the driver rather than write another similar driver.

Thank you,

---
Best Regards
Kunihiko Hayashi

Hi Kunihiko,

On 8/31/26 23:08, Kunihiko Hayashi wrote:
> Hi Judith,
> 
> Sorry for late.

No worries!

> 
> On 2026/08/13 0:44, Judith Mendez wrote:
>> This series adds support for reading AM62P silicon revision from the
>> efuse GP_SW register. The solution reuses the  existing uniphier-efuse
>> driver by adding ti,am62p-efuse as a compatible string. The three patches
>> update the devicetree binding to document the new compatible, configure
>> the driver as mandatory builtin for K3 architectures, and extend the
>> driver
>> to support AM62P devices. The uniphier-efuse driver is simple enough 
>> to be
>> reused for efuse register reads on the AM62P SoC.
> 
> Reusing the uniphier-efuse driver seems reasonable to me.
> 
> The driver is already fairly generic, and contains no arch-specific 
> elements
> that would justify introducing a dedicated driver at this point.
> 
>> Feedback is welcome on whether reusing the uniphier-efuse driver is the
>> preferred solution or if a dedicated AM62P efuse driver would be more
>> appropriate.
>>
>> Patches have been tested on AM62p SK hardware using SR1.0, SR1.1 and 
>> SR1.2
>> silicon.
> 
> Provided the functionality has been validated on the target hardware,
> I would prefer to reuse the driver rather than write another similar 
> driver.

Awesome, we send out the official v2 then. thanks!!!

~ Judith