[RFC] Issue with GPIO hog when using a pinctrl driver

[Florian Vaussard <florian.vaussard@xxxxxxxxx>]

Hi!

I recently had an issue when trying to use GPIO hog with a GPIO controller
backed by a pinctrl driver (specifically
drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c but I believe that the issue may be
broader). The gpiochip is initialized in two steps, using gpiochip_add_data()
and then gpiochip_add_pin_range(). The GPIO hog is initialized during the call
to gpiochip_add_data():

gpiochip_add_data
 -> of_gpiochip_add
     -> of_gpiochip_scan_gpios
         -> gpiod_hog

But gpiod_hog will fail because the GPIO mapping is not yet initialized by
gpiochip_add_pin_range(). Thus the call to pinctrl_get_device_gpio_range() will
return EPROBE_DEFER, which in turn makes the pinctrl to fail probing and this
does not end very well for the kernel...

gpiod_hog
 -> gpiochip_request_own_desc
     -> __gpiod_request
         -> chip->request (=> gpiochip_generic_request)
            -> pinctrl_request_gpio
                -> pinctrl_get_device_gpio_range

To test, I did a ugly call to of_gpiochip_scan_gpios() from within the pinctrl's
probe, right after gpiochip_add_pin_range(). And indeed, the GPIO hog is
correctly performed this time. Obviously this is not the right fix. Thus my
question is how this can be fixed? It seems like a chicken and egg problem.
Maybe the call to of_gpiochip_scan_gpios should be performed by
gpiochip_add_pin_range in case the GPIO range is not dynamically assigned by
gpiochip_add_data? This seems rather complicated.

Best,
Florian

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html