summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorBartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>2025-12-22 11:01:28 +0100
committerBartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>2026-01-02 10:34:32 +0100
commit49416483a953662aa53c6d9bef651757d4a95ba5 (patch)
tree8affde32dbf3c5a6146b9c1a95848eea22c5ca57 /tools/perf/scripts/python/git@git.tavy.me:linux.git
parentcb0451e33be047fff7137f58d9996370e11fb344 (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 'tools/perf/scripts/python/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions