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

[Linus Walleij]

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.
>
> [    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);

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