[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=MfU5Bde9Cp2qLaK+8TNfAiFq-UMHcaoCXc2+iLgwNPBKA@mail.gmail.com>
Date: Mon, 5 Jan 2026 16:53:54 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, Linus Walleij <linusw@...nel.org>,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH 3/3] gpio: shared: allow sharing a reset-gpios pin between
reset-gpio and gpiolib
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:
>
Hi!
I've just sent out fixes for problems #2 and #3 with you in Cc. For #1
- are you sure this is really the commit that causes it? It doesn't
seem to have anything to do with shared GPIOs.
Bartosz
Powered by blists - more mailing lists