Re: [PATCH] pinctrl: at91: fix deferred probing support

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Fri, Jul 13, 2018 at 5:27 PM Rob Herring <robh@xxxxxxxxxx> wrote:
> 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...

I think you're spot in.

This kind of problem has cropped up in these subsystems since day
one and we probably just have different lame attempts to paper
over it all over.

I suspect that what we need to do is more akin to the DRM model
which I recently learned about (drivers/gpu/drm/vc4/vc4_drv.c is a very
clean and good example) using the core kernel component
infrastructure:

1. Drivers probe() independently, doing intiialization of state
  container struct and retreiveing resources like I/O memory,
  regulators, IRQ, DMA... but no registering interfaces to
  the subsystems yet.

2. The probe of the main component (master) matches the
  subcomponents on the platform bus. In this case, whatever
  needs to come first is the master. I guess pin control.
  return component_master_add_with_match(dev, &vc4_drm_ops, match);

3. Subcomponents:
   return component_add(&pdev->dev, &vc4_dsi_ops);

4. Later on we take control over the binding order.
   the .bind callback of the main component issues
   component_bind_all(dev, drm) and there the subdevices
   are bound.

The process is perfectly reversible. The idea here is to break the
neck of the problem by doing enough set-up in probe() so that
bind() can commence with all its resources. My Nomadik driver
already makes a half-assed attempt at this (not using the component
framework) but I could refactor it to provide an example if
there is interest.

Yours,
Linus Walleij
--
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