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

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: <3cb799ed-6760-481b-991d-5d90a23b9128@samsung.com>
Date: Mon, 5 Jan 2026 18:26:06 +0100
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Bartosz Golaszewski <brgl@...nel.org>
Cc: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, Linus
	Walleij <linusw@...nel.org>, linux-gpio@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] gpio: shared: allow sharing a reset-gpios pin
 between reset-gpio and gpiolib

On 05.01.2026 13:28, Bartosz Golaszewski wrote:
> On Mon, Jan 5, 2026 at 12:50 PM Marek Szyprowski
> <m.szyprowski@...sung.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@....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