linux-kernel - Re: [PATCH v2 2/5] nvmem: add Samsung Exynos OTP support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8eea72ea-c106-4dff-979f-c1acd6b0d617@kernel.org>
Date: Thu, 13 Nov 2025 11:44:10 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Tudor Ambarus <tudor.ambarus@...aro.org>
Cc: Srinivas Kandagatla <srini@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Alim Akhtar <alim.akhtar@...sung.com>,
 Peter Griffin <peter.griffin@...aro.org>,
 André Draszik <andre.draszik@...aro.org>,
 semen.protsenko@...aro.org, willmcvicker@...gle.com,
 kernel-team@...roid.com, linux-kernel@...r.kernel.org,
 linux-samsung-soc@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 2/5] nvmem: add Samsung Exynos OTP support

On 13/11/2025 11:26, Tudor Ambarus wrote:
>>
>>>>> this can easily be just customized chipid driver - with different
>>>>> implementation of exynos_chipid_get_chipid_info().
>>>>
>>>> If the answer is no to my question above, how shall I model the device
>>>> that binds to the existing exynos-chipid driver?
>>> Just extend the existing driver.
>>>
>> So you mean I shall have something like that in DT:
>>
>> +		chipid@...00000 {
>> +			compatible = "google,gs101-chipid";
>> +			reg = <0x10000000 0xf084>;
>> +			clocks = <&cmu_misc CLK_GOUT_MISC_OTP_CON_TOP_PCLK>;
>> +			interrupts = <GIC_SPI 752 IRQ_TYPE_LEVEL_HIGH 0>;
>> +		};
>>
>> Maybe remove the interrupts because I don't need them for reading OTP regs.
>>
>> What happens in the maybe unlikely case we do want to add support for OTP
>> for GS101? How will we describe that in DT?
>>
> 
> Ah, I guess you meant to keep the node as I described it in patch 3/5,
> an efuse node with a google,gs101-otp compatible, that will bind to the
> existing exynos-chipid driver. Then if/when we add OTP support, move
> everything to a new OTP driver. That can work, yes. Unless I add some
> OTP support now, to justify the new driver. Both shall be okay, right?

Yes.

Best regards,
Krzysztof