[PATCH] regulator: mt6397: convert to arch_initcall

[PATCH] regulator: mt6397: convert to arch_initcall

[Henry Chen]

Due to some device may need reulator operation in earlier boot time like gpu module which
power domain need regulator power on first. Move regulator of mt6397
initialization earlier in boot so that real devices can use regulator
without probe deferring.

Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
---
 drivers/regulator/mt6397-regulator.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/mt6397-regulator.c b/drivers/regulator/mt6397-regulator.c
index a5b2f47..9b89023 100644
--- a/drivers/regulator/mt6397-regulator.c
+++ b/drivers/regulator/mt6397-regulator.c
@@ -324,7 +324,11 @@ static struct platform_driver mt6397_regulator_driver = {
 	.probe = mt6397_regulator_probe,
 };
 
-module_platform_driver(mt6397_regulator_driver);
+static int __init mt6397_regulator_init(void)
+{
+	return platform_driver_register(&mt6397_regulator_driver);
+}
+arch_initcall(mt6397_regulator_init);
 
 MODULE_AUTHOR("Flora Fu <flora.fu@mediatek.com>");
 MODULE_DESCRIPTION("Regulator Driver for MediaTek MT6397 PMIC");
-- 
1.9.1

[PATCH] regulator: mt6397: convert to arch_initcall

[Mark Brown]

On Wed, Dec 23, 2015 at 06:16:08PM +0800, Henry Chen wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> Due to some device may need reulator operation in earlier boot time like gpu module which
> power domain need regulator power on first. Move regulator of mt6397
> initialization earlier in boot so that real devices can use regulator
> without probe deferring.

Several problems here.  One is that we usually use subsys_initcall() for
working around the known broken subsystems here, why have you decided to
go for arch_initcall() instead.  Another is that you're saying this is
for GPUs but I'm not aware of any reason why GPUs are broken and we
should not be introducing new problems here - what's going on?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151223/3fc42bee/attachment.sig>

[PATCH] regulator: mt6397: convert to arch_initcall

[Yingjoe Chen]

On Wed, 2015-12-23 at 12:00 +0000, Mark Brown wrote:
> On Wed, Dec 23, 2015 at 06:16:08PM +0800, Henry Chen wrote:
> 
> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns.  Doing this makes your messages much
> easier to read and reply to.
> 
> > Due to some device may need reulator operation in earlier boot time like gpu module which
> > power domain need regulator power on first. Move regulator of mt6397
> > initialization earlier in boot so that real devices can use regulator
> > without probe deferring.
> 
> Several problems here.  One is that we usually use subsys_initcall() for
> working around the known broken subsystems here, why have you decided to
> go for arch_initcall() instead.  Another is that you're saying this is
> for GPUs but I'm not aware of any reason why GPUs are broken and we
> should not be introducing new problems here - what's going on?


These changes are related to pinctrl init order patch. The related
discussion is here:
http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003298.html

and these should really be a series:

mediatek pwrap
http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003347.html
mt6397 MFD core
http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003348.html
mt6397 regulator
http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003349.html


I think Henry use arch_initcall because that's what pinctrl patch was
using. In this case, we should use subsys_initcall for all these.

Joe.C

[PATCH] regulator: mt6397: convert to arch_initcall

[Mark Brown]

On Thu, Dec 24, 2015 at 04:10:43PM +0800, Yingjoe Chen wrote:

> These changes are related to pinctrl init order patch. The related
> discussion is here:
> http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003298.html

So this is just to cut down on probe deferrals?  Sorry but as you'll see
from the discussion in that thread I'm really not enthusiastic about
taking such patches.  Trying to use initcall ordering is a hack we're
moving towards removing, isn't very robust and makes it harder to
convince people that it's worth doing anything to really improve things.

> I think Henry use arch_initcall because that's what pinctrl patch was
> using. In this case, we should use subsys_initcall for all these.

But why?  This sort of random unexplained level picking is part of the
problem...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160105/a94a7790/attachment.sig>