Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both read-only and wp-gpios

[Marek Vasut <marex@nabladev.com>]

On 4/23/26 9:42 AM, Bartosz Golaszewski wrote:
> On Wed, Apr 22, 2026 at 7:01 PM Marek Vasut <marex@nabladev.com> wrote:
>>
>> On 4/22/26 1:33 PM, Marek Vasut wrote:
>>> On 4/22/26 11:07 AM, Bartosz Golaszewski wrote:
>>>> On Tue, Apr 21, 2026 at 4:08 PM Marek Vasut <marex@nabladev.com> wrote:
>>>>>
>>>>> Handle special-case of AT24 EEPROM described in DT, which contains both
>>>>> "read-only" and "wp-gpios" properties. Interpret this configuration as
>>>>> default read-only, but with the possibility of unlock via force_ro sysfs
>>>>> attribute.
>>>>>
>>>>
>>>> Patch looks ok code-wise but does this really make sense? If an EEPROM
>>>> is read-only, we should forbid writes in the kernel. Which board uses
>>>> it? Can we simply remove the read-only flag from DT?
>>>
>>> Currently I am not aware of any upstream users, I plan to introduce one
>>> once this patch or some for of it lands.
>>
>> I have to amend my statement, I would also like to adjust an already
>> upstream DT to make use of this default-read-only functionality now.
>>
>> I would however like to get go/no-go on this patch before I roll out the
>> DT patches.
>>
> 
> Yes, go ahead.
> 
>>> I have is an ID EEPROM which I would like to be able to program under
>>> special circumstances (hence the wp-gpios control) , but it should be by
>>> default read-only .
>>>
>>> If I remove the read-only, then by default the EEPROM is read-write,
>>> which is undesired. If I remote wp-gpios then I loose access to the
>>> force_ro attribute which controls the nWP GPIO from userspace, which is
>>> undesired.
>>>
>>> So I think defining this special-case where wp-gpios and read-only are
>>> used together as default-read-only is sensible.
>>>
>>>> Admittedly: the DT bindings do allow it as read-only and wp-gpios are
>>>> not mutually exclusive but I think it's more of an accidental omission
>>>> than a planned feature.
>>> I think it is currently an undefined behavior, and this patch defines it.
>>
>> Also, this default-read-only behavior is effectively the same behavior
>> like the eMMC HW BOOT partitions have, they are also default read-only,
>> but can be switched and written to by setting their force_ro sysfs
>> attribute.
> 
> I see. Ok, please send a v2.
Does this patch require any changes ?

I will be sending the DT changes separately.