On Fri, Jul 13, 2018 at 3:47 AM Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> wrote: > > Hi Rob, > > On 12/07/2018 13:22:22-0600, Rob Herring wrote: > > 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 <plagnioj@xxxxxxxxxxxx> > > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> > > Cc: Nicolas Ferre <nicolas.ferre@xxxxxxxxxxxxx> > > Cc: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> > > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > > Cc: linux-gpio@xxxxxxxxxxxxxxx > > Signed-off-by: Rob Herring <robh@xxxxxxxxxx> > > --- > > 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 -- 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