Re: [PATCH 2/3] nvmem: Add read-only SpacemiT K3 eFuse support

["Troy Mitchell" <troy.mitchell@linux.spacemit.com>]

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

On Sat Nov 7, 2026 at 4:22 AM GMT, Yao Zi wrote:
> On Fri, Nov 06, 2026 at 02:05:24PM +0800, Jiayu Du wrote:
>> Add read-only NVMEM access to bank 0 and bank 7 of the SpacemiT K3 eFuse
>> controller. These banks contain temperature calibration parameters and
>> other configuration data.
>> 
>> Snapshot the shadow registers with aligned 32-bit reads and expose the
>> data in little-endian order at controller-relative offsets. Serve reads
>> from the snapshot and use keepouts for the remaining register ranges.
>> Keep the AES_WTM clock enabled and its shared reset deasserted while the
>> provider is registered.
>> 
>> Signed-off-by: Jiayu Du <duge1256@gmail.com>
>> ---
>>  MAINTAINERS                       |   1 +
>>  drivers/nvmem/Kconfig             |  14 +++
>>  drivers/nvmem/Makefile            |   1 +
>>  drivers/nvmem/spacemit-k3-efuse.c | 151 ++++++++++++++++++++++++++++++
>>  4 files changed, 167 insertions(+)
>>  create mode 100644 drivers/nvmem/spacemit-k3-efuse.c
>
> ...
>
>> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
>> index d2f5bb236663..28d6c59fbd74 100644
>> --- a/drivers/nvmem/Kconfig
>> +++ b/drivers/nvmem/Kconfig
>> @@ -476,6 +476,20 @@ config NVMEM_SNVS_LPGPR
>>  	  This driver can also be built as a module. If so, the module
>>  	  will be called nvmem-snvs-lpgpr.
>>  
>> +config NVMEM_SPACEMIT_K3_EFUSE
>> +	tristate "SpacemiT K3 eFuse support"
>> +	depends on ARCH_SPACEMIT || COMPILE_TEST
>> +	depends on OF && HAS_IOMEM
>> +	depends on COMMON_CLK && RESET_CONTROLLER
>> +	help
>> +	  Say Y here to read configuration and calibration data from the
>> +	  SpacemiT K3 eFuse shadow banks. The boot firmware must have loaded
>> +	  the shadow registers before Linux starts. Programming and reloading
>> +	  the fuses are not supported.
>
> I didn't read K3's TRM, but is there a reason to depend on the
> bootloader to do so? We should depend on the state set up by bootloaders
> as less as possible, I think.
The GEU hardware loads the shadow after reset. So YES, we don't need to
rely on bootloader.

-- 
Troy Mitchell


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]