[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9948f635-b753-44cf-8977-7fee4cfb6e3d@sirena.org.uk>
Date: Tue, 6 Jan 2026 12:21:09 +0000
From: Mark Brown <broonie@...nel.org>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>,
Linus Walleij <linusw@...nel.org>,
Bartosz Golaszewski <brgl@...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 05, 2026 at 12:50:22PM +0100, Marek Szyprowski 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.
> 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.
Not sure if it's this specific patch (one of the bisects identified it,
but I'm seeing others going to the merge commit for the gpio fixes
branch) but I'm also seeing issues with gpios. pwrseq is affected on
several platforms after backtraces that look a lot like the one that
Marek is seeing on Raspberry Pi 3B+ (which I also see). This breaks at
least the WiFi:
[ 13.475670] platform wifi-pwrseq: deferred probe pending: pwrseq_simple: reset control not ready
Raspberry Pi 4:
https://lava.sirena.org.uk/scheduler/job/2335022#L1200
Toradax Mallow (TI K3):
https://lava.sirena.org.uk/scheduler/job/2335415#L1457
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists