Thread (10 messages) 10 messages, 6 authors, 2023-01-27

[PATCH] pinctrl: at91: fix deferred probing support

From: robh@kernel.org (Rob Herring)
Date: 2018-07-13 15:27:42
Also in: linux-gpio

On Fri, Jul 13, 2018 at 3:47 AM Alexandre Belloni
[off-list ref] wrote:
Hi Rob,

On 12/07/2018 13:22:22-0600, Rob Herring wrote:
quoted
AT91 pinctrl deferred probing support is broken if the GPIO devices
haven't probed first and set gpio_banks to non-zero. The later condition
that only some GPIO devices haven't probed can't actually happen as
either all the GPIO devices have probed first or none of them have. Plus
the pinctrl driver has already returned -EINVAL, so it's not on the
deferred list to retry probing.

Fix this by consolidating the checking that all GPIO devices are probed.

Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Linus Walleij <redacted>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-gpio at vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
This is a result of trying to remove of_platform_default_populate from
at91 code and relying on the DT core handling populating devices. That
changed the probe order and broke booting.
This solves part of the issue but when tested with the
of_platform_default_populate removal, many drivers will fail with
gpiod_set_value: invalid GPIO (errorpointer)

or

gpiod_get_value: invalid GPIO (errorpointer)

This happens both before and after the pinctrl driver probed.

I didn't investigate much yet.
Looks to me like it may be a circular dependency. The GPIO request
functions depend on the pinctrl driver which depends on the gpio
driver. Maybe returning EPROBE_DEFER in at91_gpio_request_enable and
removing the requirement that the GPIO driver probe first would fix
it...

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help