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

[Kever Yang]

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

>
> 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