[PATCH V1] regulator: fixed: Move drivers to subsys_initcall_sync()

[PATCH V1] regulator: fixed: Move drivers to subsys_initcall_sync()

[Laxman Dewangan]

From: Laxman Dewangan <ldewangan@nvidia.com>

The fixed regulator is used to enable/disable rails which are
mainly controlled by the switch. The switches are toggled by
gpio apis.
The switches are connected through on-chip gpios or through
external devices' gpios like mfd, i2c based gpio expander etc.
The registration of the fixed regulator get success only if the
required gpios are already available in the system at this time.
The on-chip gpios are available till this time as on-chip gpios
are initialized in arch_init(). But external peripheral's gpios
may not be available at this time as they get initialized as part
of subsys_initcall() and due to this registration of the fixed
regulator may fails.
Moving the driver to subsys_initcall_sync() will make sure that
all gpios i.e. on-chip gpios as well as external peripheral's gpios
are available before fixed regulator registration.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
 drivers/regulator/fixed.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index a44a017..baec76e 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -307,7 +307,7 @@ static int __init regulator_fixed_voltage_init(void)
 {
 	return platform_driver_register(&regulator_fixed_voltage_driver);
 }
-subsys_initcall(regulator_fixed_voltage_init);
+subsys_initcall_sync(regulator_fixed_voltage_init);
 
 static void __exit regulator_fixed_voltage_exit(void)
 {
-- 
1.7.1.1

Re: [PATCH V1] regulator: fixed: Move drivers to subsys_initcall_sync()

[Mark Brown]

On Wed, Jan 04, 2012 at 09:38:55PM +0530, Laxman Dewangan wrote:
> From: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> The fixed regulator is used to enable/disable rails which are
> mainly controlled by the switch. The switches are toggled by
> gpio apis.
> The switches are connected through on-chip gpios or through
> external devices' gpios like mfd, i2c based gpio expander etc.
> The registration of the fixed regulator get success only if the
> required gpios are already available in the system at this time.
> The on-chip gpios are available till this time as on-chip gpios
> are initialized in arch_init(). But external peripheral's gpios
> may not be available at this time as they get initialized as part
> of subsys_initcall() and due to this registration of the fixed
> regulator may fails.
> Moving the driver to subsys_initcall_sync() will make sure that
> all gpios i.e. on-chip gpios as well as external peripheral's gpios
> are available before fixed regulator registration.

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
probe retry stuff or something else to solve the init ordering issues
properly.

RE: [PATCH V1] regulator: fixed: Move drivers to subsys_initcall_sync()

[Laxman Dewangan]

> From: linux-pm-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-pm-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org]
> On Behalf Of Mark Brown
> Sent: Thursday, January 05, 2012 11:29 AM


> > The fixed regulator is used to enable/disable rails which are
> > mainly controlled by the switch. The switches are toggled by
> > gpio apis.
> > The switches are connected through on-chip gpios or through
> > external devices' gpios like mfd, i2c based gpio expander etc.
> > The registration of the fixed regulator get success only if the
> > required gpios are already available in the system at this time.
> > The on-chip gpios are available till this time as on-chip gpios
> > are initialized in arch_init(). But external peripheral's gpios
> > may not be available at this time as they get initialized as part
> > of subsys_initcall() and due to this registration of the fixed
> > regulator may fails.
> > Moving the driver to subsys_initcall_sync() will make sure that
> > all gpios i.e. on-chip gpios as well as external peripheral's gpios
> > are available before fixed regulator registration.
> 
> 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
> probe retry stuff or something else to solve the init ordering issues
> properly.
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?

Re: [PATCH V1] regulator: fixed: Move drivers to subsys_initcall_sync()

[Mark Brown]

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.

RE: [PATCH V1] regulator: fixed: Move drivers to subsys_initcall_sync()

[Laxman Dewangan]

> From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-owner@vger.kernel.org]
> On Behalf Of Mark Brown
> Sent: Friday, January 06, 2012 12:24 PM

> > 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.

Completely agree with you. I went through the Grant's change 
" drivercore: Add driver probe deferral mechanism" and it is
discussed in more details here. I will start different thread
communication on this issue.


> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html