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 18:26, Marek Szyprowski wrote:
> 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.
>
I think that everything is in the call stack:

Call trace:
  gpiod_direction_input_nonotify+0x20/0x39c (P)
  gpiod_configure_flags+0x23c/0x480
  gpiod_find_and_request+0x1a0/0x574
  gpiod_get_index+0x58/0x84
  devm_gpiod_get_index+0x20/0xb4
  devm_gpiod_get_optional+0x18/0x30
  samsung_dsim_host_attach+0x1c8/0x284
  mipi_dsi_attach+0x30/0x54
  s6e3ha2_probe+0x148/0x200 [panel_samsung_s6e3ha2]

...


The issue is in gpiod_direction_input_nonotify+0x20/0x39c:

$ grep gpiod_direction_input_nonotify System.map
ffff800080810360 T gpiod_direction_input_nonotify

$ aarch64-linux-gnu-addr2line -f -e vmlinux ffff800080810380
class_gpio_chip_guard_constructor
/home/m.szyprowski/dev/kernel/linux-next/drivers/gpio/gpiolib.h:231

IMHO it looks that gpiod_configure_flags() is called for NULL gpio_chip.

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