Re: [PATCH 3/3] gpio: shared: allow sharing a reset-gpios pin between reset-gpio and gpiolib

[Marek Szyprowski <m.szyprowski@samsung.com>]

On 05.01.2026 13:28, Bartosz Golaszewski wrote:
> On Mon, Jan 5, 2026 at 12:50 PM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 22.12.2025 11:01, Bartosz Golaszewski wrote:
>>> 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")
>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>> This patch landed in linux-next as commit 49416483a953 ("gpio: shared:
>> allow sharing a reset-gpios pin between reset-gpio and gpiolib"). In my
>> tests I found that it breaks booting and triggers warnings on some of my
>> test boards. Reverting it on top of next-20260105 fixes those issues.
>> Let me know if I can help debugging this issue.
>>
>>
>> Here are relevant logs from my 3 test systems:
>>
> Thanks for the report.
>
> Nice combo, it looks like these are three separate bugs...
>
>> 1. Samsung TM2e - arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
>>
>> exynos-dsi 13900000.dsi: [drm:samsung_dsim_host_attach] Attached s6e3hf2
>> device (lanes:4 bpp:24 mode-flags:0x6e0)
>> Unable to handle kernel NULL pointer dereference at virtual address
> Could you use faddr2line to point me to the exact offending line? This
> would speed up the debugging.

I need some time to get that output, but this issue is caused by a 
devm_gpiod_get_optional() call for a gpio that is not defined for that 
board.

> > ...

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland