linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Rob Herring <robh@kernel.org>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	sudeep.holla@arm.com, cristian.marussi@arm.com,
	krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
	Oleksii_Moisieiev@epam.com, linux-arm-kernel@lists.infradead.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-gpio@vger.kernel.org
Subject: Re: [RFC v2 5/5] dt-bindings: gpio: Add bindings for pinctrl based generic gpio driver
Date: Mon, 9 Oct 2023 09:49:33 +0200	[thread overview]
Message-ID: <CACRpkdaLsfSBEG-h9ZNT2_Lm8tW8AZO7tedDVNeuZoQAqSkyjw@mail.gmail.com> (raw)
In-Reply-To: <20231006132346.GA3426353-robh@kernel.org>

On Fri, Oct 6, 2023 at 3:23 PM Rob Herring <robh@kernel.org> wrote:
> On Thu, Oct 05, 2023 at 11:58:43AM +0900, AKASHI Takahiro wrote:

> > A dt binding for pin controller based generic gpio driver is defined in
> > this commit. One usable device is Arm's SCMI.
>
> You don't need a "generic" binding to have a generic driver. Keep the
> binding specific and then decide in the OS to whether to use a generic
> or specific driver. That decision could change over time, but the
> binding can't. For example, see simple-panel.

What you say is true for simple-panel (a word like "simple" should
always cause red flags).

This case is more like mfd/syscon.yaml, where the singular
compatible = "syscon"; is in widespread use:

$ git grep 'compatible = \"syscon\";' |wc -l
50

I would accept adding a tuple compatible if you insist, so:

compatible = "foo-silicon", "pin-contro-gpio";

One case will be something like:

compatible = "optee-scmi-pin-control", "pin-control-gpio";

In this case I happen to know that we have the problem of
this being standardization work ahead of implementation on
actual hardware, and that is driven by the will known firmware
ambition to be completely abstract. It is supposed to sit on
top of pin control, or as part of pin control. Which leads me to
this thing (which I didn't think of before...)

> +    gpio0: gpio@0 {
> +        compatible = "pin-control-gpio";
> +        gpio-controller;
> +        #gpio-cells = <2>;
> +        gpio-ranges = <&scmi_pinctrl 0 10 5>,
> +                      <&scmi_pinctrl 5 0 0>;
> +        gpio-ranges-group-names = "",
> +                                  "pinmux_gpio";
> +    };

Maybe we should require that the pin-control-gpio node actually
be *inside* the pin control node, in this case whatever the label
&scmi_pinctrl is pointing to?

We can probably mandate that this has to be inside a pin controller
since it is a first.

Yours,
Linus Walleij

  reply	other threads:[~2023-10-09  7:49 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05  2:58 [RFC v2 0/5] gpio: add pinctrl based generic gpio driver AKASHI Takahiro
2023-10-05  2:58 ` [RFC v2 1/5] pinctrl: define PIN_CONFIG_INPUT AKASHI Takahiro
2023-10-10 11:53   ` Linus Walleij
2023-10-05  2:58 ` [RFC v2 2/5] pinctrl: always export pin_config_get_for_pin() AKASHI Takahiro
2023-10-10 11:54   ` Linus Walleij
2023-10-05  2:58 ` [RFC v2 3/5] pinctrl: add pinctrl_gpio_get_config() AKASHI Takahiro
2023-10-05  2:58 ` [RFC v2 4/5] gpio: add pinctrl based generic gpio driver AKASHI Takahiro
2023-10-10 12:00   ` Linus Walleij
2023-10-12  1:08     ` AKASHI Takahiro
2023-10-05  2:58 ` [RFC v2 5/5] dt-bindings: gpio: Add bindings for " AKASHI Takahiro
2023-10-05 19:48   ` Krzysztof Kozlowski
2023-10-12  1:15     ` AKASHI Takahiro
2023-10-12  7:27       ` Krzysztof Kozlowski
2023-10-06 13:18   ` Rob Herring
2023-10-06 13:23   ` Rob Herring
2023-10-09  7:49     ` Linus Walleij [this message]
2023-10-09  9:08       ` Cristian Marussi
2023-10-09 13:13         ` Linus Walleij
2023-10-09 15:08           ` Cristian Marussi
2023-10-10  5:14             ` AKASHI Takahiro
2023-10-10  5:25       ` AKASHI Takahiro
2023-10-12  7:25         ` Linus Walleij
2023-10-17  2:32           ` AKASHI Takahiro
2023-10-23  8:12             ` Linus Walleij
2023-10-24  7:12               ` AKASHI Takahiro
2023-10-24  9:40                 ` Linus Walleij
2023-10-24 10:55                   ` Cristian Marussi
2023-10-24 13:01                     ` Linus Walleij
2023-10-24 11:09                   ` AKASHI Takahiro
2023-10-24 13:12                     ` Linus Walleij
2023-10-24 13:42                       ` AKASHI Takahiro
2023-11-05 22:15                         ` Linus Walleij
2023-10-19 21:27 ` [RFC v2 0/5] gpio: add " andy.shevchenko
2023-10-20  0:21   ` AKASHI Takahiro

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=CACRpkdaLsfSBEG-h9ZNT2_Lm8tW8AZO7tedDVNeuZoQAqSkyjw@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=Oleksii_Moisieiev@epam.com \
    --cc=conor+dt@kernel.org \
    --cc=cristian.marussi@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=takahiro.akashi@linaro.org \
    /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;
as well as URLs for NNTP newsgroup(s).