From: Sascha Hauer <sha@pengutronix.de>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: Andrej Picej <andrej.picej@norik.com>, barebox@lists.infradead.org
Subject: Re: [PATCH 2/2] mfd: da9063: ensure all gpio devices are probed before
Date: Wed, 16 Mar 2022 11:44:40 +0100 [thread overview]
Message-ID: <20220316104440.GR405@pengutronix.de> (raw)
In-Reply-To: <ad203551-3b95-4ce8-d060-a10de337af5a@pengutronix.de>
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@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 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2022-03-16 10:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-15 13:39 [PATCH 1/2] of: implement new of_device_ensured_probed_by_alias_stem Andrej Picej
2022-03-15 13:39 ` [PATCH 2/2] mfd: da9063: ensure all gpio devices are probed before Andrej Picej
2022-03-15 14:24 ` Ahmad Fatoum
2022-03-16 10:44 ` Sascha Hauer [this message]
2022-03-21 9:46 ` Andrej Picej
2022-03-15 14:16 ` [PATCH 1/2] of: implement new of_device_ensured_probed_by_alias_stem Ahmad Fatoum
2022-03-15 14:29 ` Ahmad Fatoum
2022-03-16 10:01 ` Andrej Picej
2022-03-16 7:29 ` Andrej Picej
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220316104440.GR405@pengutronix.de \
--to=sha@pengutronix.de \
--cc=a.fatoum@pengutronix.de \
--cc=andrej.picej@norik.com \
--cc=barebox@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox