[PATCH v2 2/5] nvmem: add Samsung Exynos OTP support
Krzysztof Kozlowski
krzk at kernel.org
Thu Nov 13 02:44:10 PST 2025
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 at 10000000 {
>> + 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
More information about the linux-arm-kernel
mailing list