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

Simon Glass sjg at chromium.org
Mon Jul 29 19:21:49 CEST 2024


Hi Chris,

On Mon, 29 Jul 2024 at 10:45, Chris Webb <chris at arachsys.com> wrote:
>
> Hi Simon,
>
> Simon Glass <sjg at chromium.org> wrote:
>
> > 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.
>
> Oh I see! Yes, I can see the mtk_gpiochip_register(dev) in
> mtk_pinctrl_common_probe() exactly as you say.
>
> > 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().
>
> Yes, that makes complete sense. Many thanks! I'm very happy to write that
> patch and grab back the physical hardware to double-check on if you like?
> (Or equally happy to leave it if you'd prefer to fix yourself?)

OK good. Please go ahead!

>
> Presumably it needs to apply to every mtk soc that uses
> mtk_pinctrl_common_probe() as they'll all be affected by this problem.

Yes I suppose so.

Regards,
Simon


More information about the U-Boot mailing list