If a GPIO driver uses gpiochip_add_pin_range() (which is usually the
case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT
doesn't work:
requesting hog GPIO led1-high (chip r8a73a4_pfc, offset 28) failed
The actual error code is -517 == -EPROBE_DEFER.
The problem is that PFC+GPIO registration is handled in multiple steps:
1. pinctrl_register(),
2. gpiochip_add(),
3. gpiochip_add_pin_range().
Configuration of the hogs is handled in gpiochip_add():
gpiochip_add
of_gpiochip_add
of_gpiochip_scan_hogs
gpiod_hog
gpiochip_request_own_desc
__gpiod_request
chip->request
pinctrl_request_gpio
pinctrl_get_device_gpio_range
However, at this point the GPIO controller hasn't been added to
pinctrldev_list yet, so the range can't be found, and the operation fails
with -EPROBE_DEFER.
To fix this, add a "gpio-ranges" property to the gpio device node, so
the ranges are added by of_gpiochip_add_pin_range(), which is called by
of_gpiochip_add() before the call to of_gpiochip_scan_hogs().
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
reg = <0 0xe6050000 0 0x9000>;
gpio-controller;
#gpio-cells = <2>;
+ gpio-ranges =
+ <&pfc 0 0 31>, <&pfc 32 32 9>,
+ <&pfc 64 64 22>, <&pfc 96 96 31>,
+ <&pfc 128 128 7>, <&pfc 160 160 19>,
+ <&pfc 192 192 31>, <&pfc 224 224 27>,
+ <&pfc 256 256 28>, <&pfc 288 288 21>,
+ <&pfc 320 320 10>;
interrupts-extended =
<&irqc0 0 0>, <&irqc0 1 0>, <&irqc0 2 0>, <&irqc0 3 0>,
<&irqc0 4 0>, <&irqc0 5 0>, <&irqc0 6 0>, <&irqc0 7 0>,