linux-kernel - Re: [PATCH 3/3] gpio: TODO: track the removal of GPIOD_FLAGS_BIT

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: <CACRpkdYev-uRGwsjbpnYWKUCg0QWy8ZRaFDjJRPVbHCPXPgX2A@mail.gmail.com>
Date: Tue, 15 Apr 2025 10:43:52 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH 3/3] gpio: TODO: track the removal of GPIOD_FLAGS_BIT_NONEXCLUSIVE

On Mon, Apr 7, 2025 at 2:38 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:

> I don't agree with this. I could possibly live with that being used
> exclusively in lower-level core subsystem code (for instance:
> regulator/core.c) but, in this form, this still requires drivers - who
> have no business knowing whether the GPIO they use is shared - to use
> the right API. Not to mention that once you make an interface
> available, people will be very eager to abuse it. IMO this should be
> approached from the other side.
>
> The closest thing to making the sharing opaque to consumers is
> providing a pwrseq-backed, faux GPIO chip that allows a very limited
> set of operations on GPIOs - get, get_value, set_value - and return an
> error on others. A value set would actually be equivalent to "enable
> high" and be refcounted by pwrseq. I have something in mind but this
> cycle, I already have a lot on my plate. I will get to it eventually
> and come up with some code to back my idea.
>
> In any case: the GPIO sharing logic should be hidden, I just need to
> figure out how to make it possible to be notified about when the value
> change actually happens as per Mark's requirement.
>
> Let me reiterate: a random ethernet PHY driver should not have to call
> gpiod_get_shared() or anything similar - why would it? It can be used
> in all kinds of situations, whether the GPIO is shared is none of its
> business.

I get your point, it's just that I don't see how pwrseq solves it, so I
would have to see it.

I think a bit of my problem is with the name, as in how would a
power seqeunce solve the problem of a GPIO that is shared for
something not power or reset for example.

But maybe all the existing cases we have are shared power or
reset :D

I could think of a shared LED GPIO (this LED should be on if
any consumers A...X are active) but I just made that up.

Yours,
Linus Walleij