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

From: Marc Zyngier
Date: Thu Sep 30 2021 - 04:04:11 EST


On Wed, 29 Sep 2021 20:05:42 +0100,
Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
> On Wed, Sep 29, 2021 at 6:56 PM Marc Zyngier <maz@xxxxxxxxxx> wrote:
>
> > From: Mark Kettenis <kettenis@xxxxxxxxxxx>
> >
> > 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@xxxxxxxxxxx>
> > Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
> > Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
> > Link: https://lore.kernel.org/r/20210520171310.772-3-mark.kettenis@xxxxxxxxx
> (...)
> > + 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.