[PATCH] gpio: rockchip: convert to dynamic GPIO base allocation

[Steven Price]

On 09/04/2026 23:25, Linus Walleij wrote:
> On Thu, Apr 9, 2026 at 9:09 PM Jonas Karlman <jonas at kwiboo.se> wrote:
> 
>> This patch is causing boot issues on my Rock Pi 4 (RK3399) board using
>> next-20260409 kernel where this patch has been applied as c8079f83e0bf.

I had similar problems with my Firefly RK3288.

>>
>> [    0.082771] rockchip-gpio ff720000.gpio: probed /pinctrl/gpio at ff720000
>> [    0.083531] rockchip-gpio ff730000.gpio: probed /pinctrl/gpio at ff730000
>> [    0.084110] rockchip-gpio ff780000.gpio: probed /pinctrl/gpio at ff780000
>> [    0.084746] rockchip-gpio ff788000.gpio: probed /pinctrl/gpio at ff788000
>> [    0.085389] rockchip-gpio ff790000.gpio: probed /pinctrl/gpio at ff790000
>> --
>> [    0.212208] rockchip-pinctrl pinctrl: pin 637 is not registered so it cannot be requested
>> [    0.212271] rockchip-pinctrl pinctrl: error -EINVAL: pin-637 (gpio3:637)
>> [    0.212344] leds-gpio leds: error -EINVAL: Failed to get GPIO '/leds/led-0'
>> [    0.212389] leds-gpio leds: probe with driver leds-gpio failed with error -22
> 
> I think this may be because the rk3399 is missing gpio-ranges despite it is a
> new platform and should have had its gpio-ranges defined in
> arch/arm64/boot/dts/rockchip/rk3399-base.dtsi ...
> 
> A bunch of these rockchips seem to have this problem despite the
> code in pinctrl-rockchip.c that says:
> 
>     /*
>      * For DeviceTree-supported systems, the gpio core checks the
>      * pinctrl's device node for the "gpio-ranges" property.
>      * If it is present, it takes care of adding the pin ranges
>      * for the driver. In this case the driver can skip ahead.
>      *
>      * In order to remain compatible with older, existing DeviceTree
>      * files which don't set the "gpio-ranges" property or systems that
>      * utilize ACPI the driver has to call gpiochip_add_pin_range().
>      */
>     if (!of_property_present(bank->of_node, "gpio-ranges")) {
>         struct device_node *pctlnp = of_get_parent(bank->of_node);
>         struct pinctrl_dev *pctldev = NULL;
> 
>         if (!pctlnp)
>             return -ENODATA;
> 
>         pctldev = of_pinctrl_get(pctlnp);
>         of_node_put(pctlnp);
>         if (!pctldev)
>             return -ENODEV;
> 
>         ret = gpiochip_add_pin_range(gc, dev_name(pctldev->dev), 0,
>                          gc->base, gc->ngpio);
>         if (ret) {
>             dev_err(bank->dev, "Failed to add pin range\n");
>             goto fail;
>         }
>     }
> 
> Notice dereference of gpiolib internal gc-base here.
> 
>         ret = gpiochip_add_pin_range(gc, dev_name(pctldev->dev), 0,
>                          gc->base, gc->ngpio);
> 
> arguments are gpipchip, pinctontrol device name,
> gpio offset, pin offset, number of pins.
> 
> GPIO offset always 0?? Passing GPIO offset as pin offset??
> 
> This is probably just working because of luck that 0,0 is passed.
> 
> This should probably rather be something like:
> 
>         ret = gpiochip_add_pin_range(gc, dev_name(pctldev->dev), gc->base,
>                          bank->bank_num * bank->nr_pins, gc->ngpio);

This however didn't work. Instead ChatGPT was able to suggest:

	ret = gpiochip_add_pin_range(gc, dev_name(pctldev->dev), 0,
				     bank->pin_base, gc->ngpio);

which works for me. I won't repeat the waffle from ChatGPT because I
honestly don't understand this area of the kernel (and you can ask an AI
yourself if you want to). I'm not subscribed, so please CC me if you
want me to try any alternative fixes.

Thanks,
Steve

> Here we put the assigned (by gpiolib) gc->base in the right place, then
> bank->bank_num should be 0,1,2... and bank->nr_pins always 32 (I think).
> 
> Jonas can you test this oneliner change? I can send a proper patch
> if it helps.
> 
> If this works the DTS files can (SHOULD) be fixed with proper ranges later.
> 
> It would be nice if we could augment the rockchip pinctrl DT schema to
> make gpio-ranges mandatory on new SoCs.
> 
> Yours,
> Linus Walleij
>