[PATCH RFC] gpio: Fix probing of gpio-hogs

Simon Glass sjg at chromium.org
Mon Jul 29 18:18:03 CEST 2024


Hi Chris,

On Mon, 29 Jul 2024 at 09:44, Chris Webb <chris at arachsys.com> wrote:
>
> Simon Glass <sjg at chromium.org> wrote:
>
> > We cannot probe devices when they are bound since it breaks the
> > ordering of driver model.
> >
> > From your trace it looks like everything is happening after
> > relocation. I can't quite see what is actually going wrong. But if you
> > look at dm_init_and_scan(), it does the probe at the end, immediately
> > after all devices have been bound. So it should do what you want.
> >
> > Is the GPIO device not being bound? There is something strange here.
>
> Hi Simon, many thanks for your follow up. Yes I wasn't convinced the patch
> was the correct fix (hence the RFC) but posted as it was one of the two
> ways I found to make gpio-hog work, the other being adding a .bind
> function in U_BOOT_DRIVER(mt7981_pinctrl) like
>
>      static int mtk_pinctrl_mt7981_bind(struct udevice *dev)
>      {
>         dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
>         return 0;
>      }
>
> to force a probe after bind in the parent pinctrl device. I was hoping
> someone with more clue than me might go 'Aha! This is just...'  :)
?
>
> The device I tested on has been deployed but I can probably get it back
> for a bit and resolder a serial console on to test again if that would be
> helpful. Are there other significant places I should be adding some traces
> that would make the problem clearer?
>
> Is it significant/relevant that the gpio device is a child of the pinctrl
> device in the mt7981 device tree?
>
> I think the gpio device must be getting bound, because otherwise my trace
> in gpio_post_bind() wouldn't get called at all, but perhaps it's bound too
> late somehow?

Well, yes, mt7981_pinctrl is wrong since it is not actually binding
the GPIO devices until it itself is probed. It should do it when it is
bound.

Better still, those GPIO devices should be in the devicetree and bound
automatically by driver model. But, sigh, I see that there is no
compatible string in the gpio subnode of pinctrl at 11d00000. It should
really have one and avoid all this pointless code and problems.

mtk_pinctrl_common_probe() is misnamed, as it actually binds and then probes.

So (unless Linux allows a patch to add a compatible string) it needs a
new mtk_pinctrl_common_bind() (called from mtk_pinctrl_mt7981_bind())
which calls mtk_gpiochip_register(). Then you won't need to add your
dev_or_flags() into mtk_pinctrl_mt7981_bind().

Regards,
Simon


More information about the U-Boot mailing list