[PATCH 2/2] mfd: da9063: ensure all gpio devices are probed before
Sascha Hauer
sha at pengutronix.de
Wed Mar 16 03:44:40 PDT 2022
On Tue, Mar 15, 2022 at 03:24:23PM +0100, Ahmad Fatoum wrote:
> On 15.03.22 14:39, Andrej Picej wrote:
> > GPIO lines in da9063 are assigned dynamically, while majority of SOC
> > GPIO drivers assign their GPIOs in static manner (GPIO line numbers can
> > be calculated).
> >
> > This introduces regression if deep probe support is used. If da9063
> > GPIOs are registered before the SOCs GPIOs, there is a good chance that
> > the SOCs statically computed GPIO line numbers will already be used by
> > PMIC.
> >
> > Ensure all SOCs GPIO drivers and GPIO lines get registered before the
> > da9063 registers its own gpiochip.
> >
> > Signed-off-by: Andrej Picej <andrej.picej at norik.com>
>
> I don't think this is the proper place. Also I think you may have
> introduced a recursion here if the PMIC happens to have an alias
> itself?
>
> What I think we could do instead is to move this into gpiochip_add()
> and opencode the alias iterator:
>
>
> foreach (gpio_alias) {
> if (gpio_alias_dev == chip->dev)
> __gpiochip_add();
> else
> of_device_ensure_probed();
> }
This of_device_ensure_probed() will bring you into the very same loop
again. Better call this loop from outside gpiochip_add(). We could
add a gpio_ensure_probed() which executes this loop. That would be
called from some initcall, or maybe from board code when gpios are
needed before this initcall.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the barebox
mailing list