[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