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

[Chris Morgan]

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 at gmail.com> wrote:
> > 
> > > From: Chris Morgan <macromorgan at 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 at 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