Re: [PATCH v5 10/14] arm64: apple: Add pinctrl nodes

[Marc Zyngier <maz@kernel.org>]

On Wed, 29 Sep 2021 20:05:42 +0100,
Linus Walleij <linus.walleij@linaro.org> wrote:
> 
> On Wed, Sep 29, 2021 at 6:56 PM Marc Zyngier <maz@kernel.org> wrote:
> 
> > From: Mark Kettenis <kettenis@openbsd.org>
> >
> > Add pinctrl nodes corresponding to the gpio,t8101 nodes in the
> > Apple device tree for the Mac mini (M1, 2020).
> >
> > Clock references are left out at the moment and will be added once
> > the appropriate bindings have been settled upon.
> >
> > Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > Link: https://lore.kernel.org/r/20210520171310.772-3-mark.kettenis@xs4all.nl
> (...)
> > +               pinctrl_ap: pinctrl@23c100000 {
> > +                       compatible = "apple,t8103-pinctrl", "apple,pinctrl";
> > +                       reg = <0x2 0x3c100000 0x0 0x100000>;
> > +
> > +                       gpio-controller;
> > +                       #gpio-cells = <2>;
> > +                       gpio-ranges = <&pinctrl_ap 0 0 212>;
> 
> In other discussions it turns out that the driver is abusing these gpio-ranges
> to find out how many pins are in each pinctrl instance. This is not the
> idea with gpio-ranges, these can be multiple and map different sets,
> so we need something like
> 
> apple,npins = <212>;
> (+ bindings)
> 
> or so...

Is it the driver that needs updating? Or the binding? I don't really
care about the former, but the latter is more disruptive as it has
impacts over both u-boot and at least OpenBSD.

How is that solved on other pinctrl blocks? I can't see anyone having
a similar a similar property.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.