From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: Linus Walleij <linusw@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Frank Li <Frank.Li@nxp.com>,
vjardin@free.fr
Cc: linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Vincent Jardin <vjardin@free.fr>
Subject: Re: [PATCH v2] dt-bindings: gpio: fsl,qoriq-gpio: allow gpio-hog child nodes
Date: Tue, 25 Aug 2026 08:56:22 +0200 [thread overview]
Message-ID: <13423320.O9o76ZdvQC@steina-w> (raw)
In-Reply-To: <20260824-for-upstream-dt-qoriq-gpio-hog-v2-1-58bbc82b881e@free.fr>
Am Montag, 24. August 2026, 23:54:40 CEST schrieb Vincent Jardin via B4 Relay:
> From: Vincent Jardin <vjardin@free.fr>
>
> The binding sets additionalProperties: false and describes no child nodes,
> so a gpio-hog on a QorIQ/Layerscape GPIO controller is rejected by
> dtbs_check as an unmatched node name, even though the hardware and the
> kernel both support it.
>
> Hogs are not a controller feature and need nothing from the driver:
> gpio-mpc8xxx.c does not mention them at all. A hog on this controller
> works today, only the schema rejects it.
>
> QorIQ and Layerscape boards do need them. These SoCs bring board-level
> reset, enable and mux-select lines out on the SoC GPIOs, and those lines
> have to be driven to a safe level at boot before any consumer claims them,
> which is exactly what a hog is for.
>
> Some boards in the tree already express this need where they can:
> fsl-ls1088a-ten64.dts and the tqmls1012a/ls1028a boards all carry hogs, but
> on I2C GPIO expanders, because that is the only place the schema currently
> supports them. No board uses one on this controller yet, so this fixes no
> current failure.
>
> Other GPIO bindings already carry the same block. gpio-mvebu.yaml and
> gpio-davinci.yaml use the identical "^(.+-hog(-[0-9]+)?)$" object requiring
> gpio-hog.
>
> Signed-off-by: Vincent Jardin <vjardin@free.fr>
> ---
> Changes in v2:
> - Change the commit message. Drop the dmesg excerpt: those hog names come
> from my out-of-tree dev git repo and are not in the tree (Frank Li)
> - Note: the hog call path is: gpiochip_hog_lines(), called from gpiochip_add_data_with_key()
> - Explain why these QorIQ SoCs need it
> - No change to the diff
> - Link to v1: https://lore.kernel.org/r/20260824-for-upstream-dt-qoriq-gpio-hog-v1-1-d75923bcecad@free.fr
> ---
> Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml b/Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml
> index 4cb2a6b9fabfb..a6252440e099b 100644
> --- a/Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml
> @@ -63,6 +63,13 @@ properties:
> GPIO registers are used as little endian. If not
> present registers are used as big endian by default.
>
> +patternProperties:
> + "^(.+-hog(-[0-9]+)?)$":
> + type: object
> +
> + required:
> + - gpio-hog
> +
Shouldn't you reference gpio-hog.yaml schema instead? This already has (among
others) patter and required properties. But I'm no expert on bindings.
Best regards
Alexander
> required:
> - compatible
> - reg
>
> ---
> base-commit: 0a0d1d55dad570724bf8c7ea83409639cfb4be9b
> change-id: 20260824-for-upstream-dt-qoriq-gpio-hog-5092a0f4d089
>
> Best regards,
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
next prev parent reply other threads:[~2026-08-25 7:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 21:54 [PATCH v2] dt-bindings: gpio: fsl,qoriq-gpio: allow gpio-hog child nodes Vincent Jardin via B4 Relay
2026-08-25 6:56 ` Alexander Stein [this message]
2026-08-25 9:36 ` Vincent Jardin
2026-08-25 7:09 ` Krzysztof Kozlowski
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=13423320.O9o76ZdvQC@steina-w \
--to=alexander.stein@ew.tq-group.com \
--cc=Frank.Li@nxp.com \
--cc=brgl@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=vjardin@free.fr \
/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