[PATCH] nvmem: core: Mark nWP GPIO as non-exclusive

[PATCH] nvmem: core: Mark nWP GPIO as non-exclusive

[Marek Vasut]

Mark the nWP GPIO as non-exclusive, because there is hardware in the
field which has multiple AT24 EEPROMs with nWP GPIO line tied to a
single GPIO. This allows such hardware to be described in DT and the
nWP GPIO operated via NVMEM force_ro sysfs attribute.

Note that GPIOD_FLAGS_BIT_NONEXCLUSIVE is a deprecated flag and should
not be used, but thus far there seems to be no replacement.

Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Bartosz Golaszewski <brgl@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Srinivas Kandagatla <srini@kernel.org>
Cc: linux-i2c@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/nvmem/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index be28a366f6031..4fe2fad2f88b4 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -928,7 +928,8 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
 
 	if (!config->ignore_wp)
 		nvmem->wp_gpio = gpiod_get_optional(config->dev, "wp",
-						    GPIOD_OUT_HIGH);
+						    GPIOD_OUT_HIGH |
+						    GPIOD_FLAGS_BIT_NONEXCLUSIVE);
 	if (IS_ERR(nvmem->wp_gpio)) {
 		rval = PTR_ERR(nvmem->wp_gpio);
 		nvmem->wp_gpio = NULL;
-- 
2.53.0

Re: [PATCH] nvmem: core: Mark nWP GPIO as non-exclusive

[Bartosz Golaszewski]

On Mon, May 11, 2026 at 6:35 PM Marek Vasut <marex@nabladev.com> wrote:
>
> Mark the nWP GPIO as non-exclusive, because there is hardware in the
> field which has multiple AT24 EEPROMs with nWP GPIO line tied to a
> single GPIO. This allows such hardware to be described in DT and the
> nWP GPIO operated via NVMEM force_ro sysfs attribute.
>
> Note that GPIOD_FLAGS_BIT_NONEXCLUSIVE is a deprecated flag and should
> not be used, but thus far there seems to be no replacement.
>

There is a replacement now. It lives under
drivers/gpio/gpiolib-shared.c and drivers/gpio/gpio-shared-proxy.c.
Though the voting mechanism I implemented is hard-coded to drive the
line high if there's at least one consumer sharing the line that votes
high. I'm now thinking that this may be too rigid as yesterday, within
two hours I had two submissions wanting to do it the other way around
- drive the line low if there's at least one consumer that wants it
low.

I'll try to modify the gpio-shared-proxy driver to take into account
the value set when the line is first requested and treat it as the
"default" in the voting mechanism. IOW: when the first user requests
it out-high, we'll drive it low on the first user that votes for low
and drive it high again when the last user drivers it high. This
should work for both the Qualcomm shared GPIOs for audio use-cases and
the WP pin here as well as the SCL recovery shared GPIO we have in
I2C.

With that said: I'd prefer you not set the
GPIOD_FLAGS_BIT_NONEXCLUSIVE and see if you can make gpio-shared-proxy
work for you instead. I'll submit something soon for you to test.

Bart

Re: [PATCH] nvmem: core: Mark nWP GPIO as non-exclusive

[Marek Vasut]

On 5/12/26 12:04 PM, Bartosz Golaszewski wrote:
> On Mon, May 11, 2026 at 6:35 PM Marek Vasut <marex@nabladev.com> wrote:
>>
>> Mark the nWP GPIO as non-exclusive, because there is hardware in the
>> field which has multiple AT24 EEPROMs with nWP GPIO line tied to a
>> single GPIO. This allows such hardware to be described in DT and the
>> nWP GPIO operated via NVMEM force_ro sysfs attribute.
>>
>> Note that GPIOD_FLAGS_BIT_NONEXCLUSIVE is a deprecated flag and should
>> not be used, but thus far there seems to be no replacement.
>>
> 
> There is a replacement now. It lives under
> drivers/gpio/gpiolib-shared.c and drivers/gpio/gpio-shared-proxy.c.
> Though the voting mechanism I implemented is hard-coded to drive the
> line high if there's at least one consumer sharing the line that votes
> high. I'm now thinking that this may be too rigid as yesterday, within
> two hours I had two submissions wanting to do it the other way around
> - drive the line low if there's at least one consumer that wants it
> low.
> 
> I'll try to modify the gpio-shared-proxy driver to take into account
> the value set when the line is first requested and treat it as the
> "default" in the voting mechanism. IOW: when the first user requests
> it out-high, we'll drive it low on the first user that votes for low
> and drive it high again when the last user drivers it high. This
> should work for both the Qualcomm shared GPIOs for audio use-cases and
> the WP pin here as well as the SCL recovery shared GPIO we have in
> I2C.
Shouldn't the polarity inversion be handled by DT GPIO_ACTIVE_* flags 
instead ?

Re: [PATCH] nvmem: core: Mark nWP GPIO as non-exclusive

[Marek Vasut]

On 5/12/26 12:04 PM, Bartosz Golaszewski wrote:
> On Mon, May 11, 2026 at 6:35 PM Marek Vasut <marex@nabladev.com> wrote:
>>
>> Mark the nWP GPIO as non-exclusive, because there is hardware in the
>> field which has multiple AT24 EEPROMs with nWP GPIO line tied to a
>> single GPIO. This allows such hardware to be described in DT and the
>> nWP GPIO operated via NVMEM force_ro sysfs attribute.
>>
>> Note that GPIOD_FLAGS_BIT_NONEXCLUSIVE is a deprecated flag and should
>> not be used, but thus far there seems to be no replacement.
>>
> 
> There is a replacement now. It lives under
> drivers/gpio/gpiolib-shared.c and drivers/gpio/gpio-shared-proxy.c.
> Though the voting mechanism I implemented is hard-coded to drive the
> line high if there's at least one consumer sharing the line that votes
> high. I'm now thinking that this may be too rigid as yesterday, within
> two hours I had two submissions wanting to do it the other way around
> - drive the line low if there's at least one consumer that wants it
> low.
> 
> I'll try to modify the gpio-shared-proxy driver to take into account
> the value set when the line is first requested and treat it as the
> "default" in the voting mechanism. IOW: when the first user requests
> it out-high, we'll drive it low on the first user that votes for low
> and drive it high again when the last user drivers it high. This
> should work for both the Qualcomm shared GPIOs for audio use-cases and
> the WP pin here as well as the SCL recovery shared GPIO we have in
> I2C.
> 
> With that said: I'd prefer you not set the
> GPIOD_FLAGS_BIT_NONEXCLUSIVE and see if you can make gpio-shared-proxy
> work for you instead. I'll submit something soon for you to test.

I'm sorry for my late reply, I was completely overwhelmed by emails.

I tried to look into the gpio-shared* , but I couldn't figure out how to 
describe it in DT. Do you have any examples?

Take for example this DT snippet:

gpio: gpio-controller { ... };

i2c {
   eeprom@0 {
     wp-gpios = <&gpio 0 0>;
     ...
   };

   eeprom@1 {
     wp-gpios = <&gpio 0 0>;
     ...
   };
};

I assume there has to be some new glue node between the eeproms and the 
GPIO controller somewhere ?

Thank you for your help !

-- 
Best regards,
Marek Vasut

Re: [PATCH] nvmem: core: Mark nWP GPIO as non-exclusive

[Bartosz Golaszewski]

On Thu, 23 Jul 2026 21:35:27 +0200, Marek Vasut <marex@nabladev.com> said:
> On 5/12/26 12:04 PM, Bartosz Golaszewski wrote:
>> On Mon, May 11, 2026 at 6:35 PM Marek Vasut <marex@nabladev.com> wrote:
>>>
>>> Mark the nWP GPIO as non-exclusive, because there is hardware in the
>>> field which has multiple AT24 EEPROMs with nWP GPIO line tied to a
>>> single GPIO. This allows such hardware to be described in DT and the
>>> nWP GPIO operated via NVMEM force_ro sysfs attribute.
>>>
>>> Note that GPIOD_FLAGS_BIT_NONEXCLUSIVE is a deprecated flag and should
>>> not be used, but thus far there seems to be no replacement.
>>>
>>
>> There is a replacement now. It lives under
>> drivers/gpio/gpiolib-shared.c and drivers/gpio/gpio-shared-proxy.c.
>> Though the voting mechanism I implemented is hard-coded to drive the
>> line high if there's at least one consumer sharing the line that votes
>> high. I'm now thinking that this may be too rigid as yesterday, within
>> two hours I had two submissions wanting to do it the other way around
>> - drive the line low if there's at least one consumer that wants it
>> low.
>>
>> I'll try to modify the gpio-shared-proxy driver to take into account
>> the value set when the line is first requested and treat it as the
>> "default" in the voting mechanism. IOW: when the first user requests
>> it out-high, we'll drive it low on the first user that votes for low
>> and drive it high again when the last user drivers it high. This
>> should work for both the Qualcomm shared GPIOs for audio use-cases and
>> the WP pin here as well as the SCL recovery shared GPIO we have in
>> I2C.
>>
>> With that said: I'd prefer you not set the
>> GPIOD_FLAGS_BIT_NONEXCLUSIVE and see if you can make gpio-shared-proxy
>> work for you instead. I'll submit something soon for you to test.
>
> I'm sorry for my late reply, I was completely overwhelmed by emails.
>
> I tried to look into the gpio-shared* , but I couldn't figure out how to
> describe it in DT. Do you have any examples?
>
> Take for example this DT snippet:
>
> gpio: gpio-controller { ... };
>
> i2c {
>    eeprom@0 {
>      wp-gpios = <&gpio 0 0>;
>      ...
>    };
>
>    eeprom@1 {
>      wp-gpios = <&gpio 0 0>;
>      ...
>    };
> };
>
> I assume there has to be some new glue node between the eeproms and the
> GPIO controller somewhere ?
>
> Thank you for your help !
>

No, this is literally how you do it. If you enable HAVE_SHARED_GPIOs and
DEBUG_GPIO, you should see it being picked up in the kernel log.

Bartosz

Re: [PATCH] nvmem: core: Mark nWP GPIO as non-exclusive

[Marek Vasut]

On 7/24/26 9:30 AM, Bartosz Golaszewski wrote:

Hello Bartosz,

>> I tried to look into the gpio-shared* , but I couldn't figure out how to
>> describe it in DT. Do you have any examples?
>>
>> Take for example this DT snippet:
>>
>> gpio: gpio-controller { ... };
>>
>> i2c {
>>     eeprom@0 {
>>       wp-gpios = <&gpio 0 0>;
>>       ...
>>     };
>>
>>     eeprom@1 {
>>       wp-gpios = <&gpio 0 0>;
>>       ...
>>     };
>> };
>>
>> I assume there has to be some new glue node between the eeproms and the
>> GPIO controller somewhere ?
>>
>> Thank you for your help !
>>
> 
> No, this is literally how you do it. If you enable HAVE_SHARED_GPIOs and
> DEBUG_GPIO, you should see it being picked up in the kernel log.
Ah, HAVE_SHARED_GPIOS is what I did not have enabled. Is there any 
reason why this is not enabled by default ?

Thank you !

Re: [PATCH] nvmem: core: Mark nWP GPIO as non-exclusive

[Bartosz Golaszewski]

On Fri, 24 Jul 2026 14:51:08 +0200, Marek Vasut <marex@nabladev.com> said:
> On 7/24/26 9:30 AM, Bartosz Golaszewski wrote:
>
> Hello Bartosz,
>
>>> I tried to look into the gpio-shared* , but I couldn't figure out how to
>>> describe it in DT. Do you have any examples?
>>>
>>> Take for example this DT snippet:
>>>
>>> gpio: gpio-controller { ... };
>>>
>>> i2c {
>>>     eeprom@0 {
>>>       wp-gpios = <&gpio 0 0>;
>>>       ...
>>>     };
>>>
>>>     eeprom@1 {
>>>       wp-gpios = <&gpio 0 0>;
>>>       ...
>>>     };
>>> };
>>>
>>> I assume there has to be some new glue node between the eeproms and the
>>> GPIO controller somewhere ?
>>>
>>> Thank you for your help !
>>>
>>
>> No, this is literally how you do it. If you enable HAVE_SHARED_GPIOs and
>> DEBUG_GPIO, you should see it being picked up in the kernel log.
> Ah, HAVE_SHARED_GPIOS is what I did not have enabled. Is there any
> reason why this is not enabled by default ?
>

It will be. I'm doing it gradually. It's enabled for Qualcomm platforms by
default and - by extension - in arm64 defconfig. I plan to enable it for other
platforms and architectures too, I just don't want to rush it. Enabling it for
arm64 defconfig had caused quite a lot of regressions a few months ago so I
prefer to be careful.

What platform are you running this on?

Bart

Re: [PATCH] nvmem: core: Mark nWP GPIO as non-exclusive

[Marek Vasut]

On 7/27/26 3:10 PM, Bartosz Golaszewski wrote:

Hello Bartosz,

>>> No, this is literally how you do it. If you enable HAVE_SHARED_GPIOs and
>>> DEBUG_GPIO, you should see it being picked up in the kernel log.
>> Ah, HAVE_SHARED_GPIOS is what I did not have enabled. Is there any
>> reason why this is not enabled by default ?
>>
> 
> It will be. I'm doing it gradually. It's enabled for Qualcomm platforms by
> default and - by extension - in arm64 defconfig. I plan to enable it for other
> platforms and architectures too, I just don't want to rush it. Enabling it for
> arm64 defconfig had caused quite a lot of regressions a few months ago so I
> prefer to be careful.
> 
> What platform are you running this on?
NXP i.MX8M Nano (arm64)

Re: [PATCH] nvmem: core: Mark nWP GPIO as non-exclusive

[Bartosz Golaszewski]

On Mon, 27 Jul 2026 15:24:11 +0200, Marek Vasut <marex@nabladev.com> said:
> On 7/27/26 3:10 PM, Bartosz Golaszewski wrote:
>
> Hello Bartosz,
>
>>>> No, this is literally how you do it. If you enable HAVE_SHARED_GPIOs and
>>>> DEBUG_GPIO, you should see it being picked up in the kernel log.
>>> Ah, HAVE_SHARED_GPIOS is what I did not have enabled. Is there any
>>> reason why this is not enabled by default ?
>>>
>>
>> It will be. I'm doing it gradually. It's enabled for Qualcomm platforms by
>> default and - by extension - in arm64 defconfig. I plan to enable it for other
>> platforms and architectures too, I just don't want to rush it. Enabling it for
>> arm64 defconfig had caused quite a lot of regressions a few months ago so I
>> prefer to be careful.
>>
>> What platform are you running this on?
> NXP i.MX8M Nano (arm64)
>

Just consider sending the following once you can make this work for you?

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d2acfac730037..a02b37c752887 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -281,6 +281,7 @@ config ARCH_MXC
 	select PM_GENERIC_DOMAINS
 	select SOC_BUS
 	select TIMER_IMX_SYS_CTR
+	select HAVE_SHARED_GPIOS
 	help
 	  This enables support for the ARMv8 based SoCs in the
 	  NXP i.MX family.


Thanks,
Bartosz

Re: [PATCH] nvmem: core: Mark nWP GPIO as non-exclusive

[Marek Vasut]

On 7/28/26 10:32 AM, Bartosz Golaszewski wrote:

Hello Bartosz,

>>> It will be. I'm doing it gradually. It's enabled for Qualcomm platforms by
>>> default and - by extension - in arm64 defconfig. I plan to enable it for other
>>> platforms and architectures too, I just don't want to rush it. Enabling it for
>>> arm64 defconfig had caused quite a lot of regressions a few months ago so I
>>> prefer to be careful.
>>>
>>> What platform are you running this on?
>> NXP i.MX8M Nano (arm64)
>>
> 
> Just consider sending the following once you can make this work for you?
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index d2acfac730037..a02b37c752887 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -281,6 +281,7 @@ config ARCH_MXC
>   	select PM_GENERIC_DOMAINS
>   	select SOC_BUS
>   	select TIMER_IMX_SYS_CTR
> +	select HAVE_SHARED_GPIOS
>   	help
>   	  This enables support for the ARMv8 based SoCs in the
>   	  NXP i.MX family.
Will do (sorted alphabetically).

Thank you !