From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Laxman Dewangan <ldewangan.com@nvidia.com>,
"lrg@slimlogic.co.uk" <lrg@slimlogic.co.uk>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: [PATCH V1] regulator: fixed: Move drivers to subsys_initcall_sync()
Date: Thu, 5 Jan 2012 22:53:30 -0800 [thread overview]
Message-ID: <20120106065329.GC3496@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <96C9D994977DD0439FB6D3FE3B13DD907DBD3A9DEC@BGMAIL01.nvidia.com>
On Thu, Jan 05, 2012 at 01:05:25PM +0530, Laxman Dewangan wrote:
> > I don't really think this is worth faffing about with, it seems at least
> > as likely to create more problems with things that depend on the
> > regulator as it is to make the regulator work. Really we need Grant's
> Yes, I agree, the init ordering need to be done properly but this is how we
> have as of now to make ordering.
> I have the switchA which is connected on regulatorA (from PMIC) and the
> switchB which is in the gpio of the pmic. The fixed regulator registration for
> switchA and switchB are failing because it did not found the valid supply/gpio.
> The one way to resolve the call probe of the fixed regulator only when pmic
> initialization is done and it is in subsys_init().
> The other way is to do the platform device registration of the fixed regulator
> is in subsys_initcall_sync() in place of arch_init, although driver is in
> subsys_initcall() to postponed the probe calling.
> What do you suggest on this case?
Honestly I'd suggest that you contribute to the effort to get the probe
ordering handling code implemented in mainline. This just seems like a
big can of worms to open up for something that's hopefully just going to
be a short term thing. It's a real problem but this seems fairly niche
and like if we start doing more than we're already doing we're going to
end up running around chasing our own tails on this stuff. I'm really
not sure what the status is on that work, though - it may be that you
actually need to pick the patches up and push them forwards yourself.
next prev parent reply other threads:[~2012-01-06 6:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-04 16:08 [PATCH V1] regulator: fixed: Move drivers to subsys_initcall_sync() Laxman Dewangan
[not found] ` <1325693335-1905-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-01-05 5:59 ` Mark Brown
[not found] ` <20120105055900.GE11867-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-01-05 7:35 ` Laxman Dewangan
2012-01-06 6:53 ` Mark Brown [this message]
2012-01-06 11:19 ` Laxman Dewangan
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=20120106065329.GC3496@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=ldewangan.com@nvidia.com \
--cc=ldewangan@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
/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