Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
MIME-Version: 1.0
References: <20231005025843.508689-1-takahiro.akashi@linaro.org>
 <20231005025843.508689-6-takahiro.akashi@linaro.org> <20231006132346.GA3426353-robh@kernel.org>
 <CACRpkdaLsfSBEG-h9ZNT2_Lm8tW8AZO7tedDVNeuZoQAqSkyjw@mail.gmail.com>
 <ZSTgTC4cFFpofYAk@octopus> <CACRpkdYD6pkccYoy90AfzV3KT7oYkBPD2_4ZW-AXzT1eUVpchA@mail.gmail.com>
 <ZS3yK/f12Mxw9rXe@octopus> <CACRpkdarDrVkPmyDawhZ+H94S4F=dtDSDVuKegi-eNfQNDY3rg@mail.gmail.com>
 <ZTduWx7CH1ifI5Uc@octopus>
In-Reply-To: <ZTduWx7CH1ifI5Uc@octopus>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Tue, 24 Oct 2023 11:40:00 +0200
Message-ID: <CACRpkdba=echR=rZYKVbROfaOp4mzjTQ9RphHFyzqSNgE1jZqg@mail.gmail.com>
Subject: Re: [RFC v2 5/5] dt-bindings: gpio: Add bindings for pinctrl based
 generic gpio driver
To:     AKASHI Takahiro <takahiro.akashi@linaro.org>,
        Linus Walleij <linus.walleij@linaro.org>,
        Rob Herring <robh@kernel.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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Takahiro,

On Tue, Oct 24, 2023 at 9:12=E2=80=AFAM AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:

> > I think it is better of the pin controller just parse and add any
> > subdevices (GPIO or other) using of_platform_default_populate()
> > (just grep for this function and you will see how many device
> > drivers use that).
>
> IICU, then, we will have to add a "compatible" to pinctrl node
> to make of_platform_default_populate() work as expected. That is:
>
> scmi {
>     ...
>     protocol@19 {
>         compatible =3D "simple-bus"; // <- added

Hm right, but you could also use
of_platform_populate(np, NULL, NULL, dev);

Then the compatible match is of no concern.

Sorry for my lack of attention to details :/

If you want to restrict the population to a few select compatibles
(maybe only "pin-control-gpio") then you can do
that with

const struct of_device_id of_scmi_protocol_19_match_table[] =3D {
        { .compatible =3D "pin-control-gpio", },
        {}
};
of_platform_populate(np, of_scmi_protocol_19_match_table, NULL, dev);

> Is this what you meant?
> In this case, however, "protocol@19" has a mixture of sub-nodes,
> most are pinconf definitions which are the properties of the pin
> controller, while "scmi_gpio" is a separate device.

That looks good to me, it makes sense to have the GPIO as a subnode
here and mandate it with a compatible to match.

> The code will work, but is it sane from DT binding pov?

Let's let the DT people jump in on that.

> > Instead just call gpiochip_add_pin_range() directly in Linux
> > after adding the pin controller and gpio_chip.
> > C.f. drivers/pinctrl/pinctrl-sx150x.c for an example of a driver
> > doing this. In this case the SX150X is hot-plugged (on a slow
> > bus) so it needs to figure out all ranges at runtime anyway.
>
> Are you suggesting implementing a custom function for parsing "gpio-range=
s"
> and calling it in pin_control_gpio_probe() instead of a generic helper?

The generic helper will always be attempted but if there are
no ranges in the device tree, it will just continue without adding
any ranges. I suggest putting *no* ranges into the device tree.

> Or do you want to always map all the pin controller's pins to
> gpio pins as sx150x does?

I think since the SCMI firmware knows about the available line
and pins etc, it makes sense that the driver comes up with the
applicable ranges on its own (derived from the information from
the SCMI firmware) and add them, instead of trying to put that
information into the device tree at all. Just omit it, and make your
own ranges, and add them in the Linux driver with
gpiochip_add_pin_range() without involving DT at all when defining
the ranges.

I'm sorry if I'm unclear sometimes.

Yours,
Linus Walleij