From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Daniel Golle <daniel@makrotopia.org>
Cc: Linus Walleij <linusw@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Frank Wunderlich <frank-w@public-files.de>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] gpiolib: tolerate gpio-hogs lacking a hogging state
Date: Tue, 14 Jul 2026 11:45:48 +0300 [thread overview]
Message-ID: <alX3PLGgoKTgSy_-@ashevche-desk.local> (raw)
In-Reply-To: <4c67cf0839ccf57db35a826df6d8fc779531509a.1783974733.git.daniel@makrotopia.org>
On Tue, Jul 14, 2026 at 12:30:53AM +0100, Daniel Golle wrote:
> Commit d1d564ec4992 ("gpio: move hogs into GPIO core") made
> gpiochip_add_hog() return -EINVAL for hog nodes lacking any of the
> 'input', 'output-low' or 'output-high' properties. The error is
> propagated by gpiochip_hog_lines() and fails registration of the
> whole GPIO chip.
>
> The previous OF-specific implementation tolerated such nodes:
> of_parse_own_gpio() warned "no hogging state specified, bailing out"
> and of_gpiochip_add_hog() stopped processing the node without failing
> chip registration.
>
> Some boards deliberately ship hog nodes without a hogging state in
> their base devicetree and supply the state via overlay, e.g. the PCIe
> slot key selection hogs on the BananaPi R4 Pro added in
> commit e309fa232d12 ("arm64: dts: mediatek: mt7988a-bpi-r4pro: rework
> pcie gpio-hog handling"), as the polarity set in the base devicetree
> could not be overridden from an overlay.
>
> Booting such a board without an overlay applied now fails to register
> the gpiochip. On the BananaPi R4 Pro this means the MT7988A pinctrl
> device fails to probe, all peripherals including the console UART
> defer forever, and the board finally hangs when clk_disable_unused()
> gates the clocks of the UART still in use by earlycon:
>
> gpiochip_add_data_with_key: GPIOs 512..595 (pinctrl_moore) failed to register, -22
> mt7988-pinctrl 1001f000.pinctrl: error -EINVAL: Failed to add gpio_chip
> ...
> clk: Disabling unused clocks
> (hangs)
>
> Restore the previous behaviour by warning about hog nodes lacking a
> hogging state and skipping them instead of failing the registration
> of the whole GPIO chip.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
...
> - if (fwnode_property_present(fwnode, "input"))
> + if (fwnode_property_present(fwnode, "input")) {
> dflags |= GPIOD_IN;
> - else if (fwnode_property_present(fwnode, "output-low"))
> + } else if (fwnode_property_present(fwnode, "output-low")) {
> dflags |= GPIOD_OUT_LOW;
> - else if (fwnode_property_present(fwnode, "output-high"))
> + } else if (fwnode_property_present(fwnode, "output-high")) {
> dflags |= GPIOD_OUT_HIGH;
For a fix I would make it less invasive and yes, break the style, by just
replacing
> - else
> - return -EINVAL;
with
else {
gpiochip_warn(gc, "%pfwP: no hogging state specified, bailing out\n",
fwnode);
return 0;
}
> + } else {
> + gpiochip_warn(gc, "%pfwP: no hogging state specified, bailing out\n",
> + fwnode);
> + return 0;
> + }
This leads patch directly to the point. The style can be modified later on.
--
With Best Regards,
Andy Shevchenko
prev parent reply other threads:[~2026-07-14 8:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 23:30 [PATCH] gpiolib: tolerate gpio-hogs lacking a hogging state Daniel Golle
2026-07-14 8:45 ` Andy Shevchenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alX3PLGgoKTgSy_-@ashevche-desk.local \
--to=andriy.shevchenko@linux.intel.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=brgl@kernel.org \
--cc=daniel@makrotopia.org \
--cc=frank-w@public-files.de \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=mika.westerberg@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox