diff options
| author | Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> | 2025-12-22 11:01:28 +0100 |
|---|---|---|
| committer | Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> | 2026-01-02 10:34:32 +0100 |
| commit | 49416483a953662aa53c6d9bef651757d4a95ba5 (patch) | |
| tree | 8affde32dbf3c5a6146b9c1a95848eea22c5ca57 /scripts/atomic/git@git.tavy.me:linux.git | |
| parent | cb0451e33be047fff7137f58d9996370e11fb344 (diff) | |
gpio: shared: allow sharing a reset-gpios pin between reset-gpio and gpiolib
We currently support sharing GPIOs between multiple devices whose drivers
use either the GPIOLIB API *OR* the reset control API but not both at
the same time.
There's an unlikely corner-case where a reset-gpios pin can be shared by
one driver using the GPIOLIB API and a second using the reset API. This
will currently not work as the reset-gpio consumers are not described in
firmware at the time of scanning so the shared GPIO just chooses one of
the proxies created for the consumers when the reset-gpio driver performs
the lookup. This can of course conflict in the case described above.
In order to fix it: if we deal with the "reset-gpios" pin that's shared
acconding to the firmware node setup, create a proxy for each described
consumer as well as another one for the potential reset-gpio device. To
that end: rework the matching to take this into account.
Fixes: 7b78b26757e0 ("gpio: shared: handle the reset-gpios corner case")
Link: https://lore.kernel.org/r/20251222-gpio-shared-reset-gpio-proxy-v1-3-8d4bba7d8c14@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Diffstat (limited to 'scripts/atomic/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions
