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

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

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 ?