Re: [PATCH V2 1/9] gpio: gpio-rockchip: parse gpio-ranges for bank id

Chris Morgan
2023-03-02T18:20:39Z

On Thu, Mar 02, 2023 at 10:54:57AM +0800, Kever Yang wrote:
> Hi Linus,
>
> On 2023/2/23 16:59, Linus Walleij wrote:
> > On Mon, Feb 13, 2023 at 11:28 PM Chris Morgan <macroalpha82@gmail.com> wrote:
> >
> > > From: Chris Morgan <macromorgan@hotmail.com>
> > >
> > > Use the new devicetree property of gpio-ranges to determine the GPIO
> > > bank ID. Preserve the "old" way of doing things too, so that boards
> > > can be migrated and tested gradually (I only have a 3566 and 3326 to
> > > test).
> > >
> > > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> > gpio-ranges are not supposed to be used like this, because there is
> > no semantic restrictions on how gpio-ranges are set up. For example:
> >
> > gpio-ranges = <&pfc 0 0 32>;
> >
> > that looks nice for this usecase, and I guess this is something
> > like what you have but then look at this from arch/arm/boot/dts/hi3620.dtsi:
> >
> > gpio-ranges = < &pmx0 0 14 1 &pmx0 1 15 1 &pmx0 2 16 1
> > &pmx0 3 16 1 &pmx0 4 16 1 &pmx0 5 16 1
> > &pmx0 6 16 1 &pmx0 7 16 1>;
>
> I can understand the gpio-ranges and pinctrl framework are flexible enough
> for different hardware.
>
> Rockchip SoC do not have this kind of GPIO/PINMUX hardware, one bank GPIO is
> always
>
> in one pinctrl/ioc for now, so this driver do work for rockchip platform in
> U-Boot for now.
>
>
> Thanks,
>
> - Kever

I think I jumped the gun (sorry, just anxious to get my hardware supported)
and it looks like Linux is going in a different direction. I'm going to work
with this for now, but once Linux decides on a correct direction I'll update
the driver in U-Boot to match the Linux behavior.

Thank you.

>
> >
> > This is perfectly fine as well. Ranges can start anywhere in the hardware
> > offsets and go anywhere, and be set up in smaller chunks however
> > the author of the DTS file wants it.
> >
> > I am pretty sure the same discontiguous
> > ranges can be encoded into the rk_gpio relevant DTS files as well,
> > so this is not a good solution to your problem.
> >
> > What has been used in the past is just some unique hardware ID in the
> > device tree, so I would just add that.
> >
> > Yours,
> > Linus Walleij