[v2,1/4] nvmem: rockchip-efuse: Change initcall to subsys

Commit Message

Finley Xiao Aug. 18, 2016, 8:52 a.m. UTC

From: Finley Xiao <[e-mail]>

We will register a cpufreq notifier for adjusting opp's voltage, and it
need to fetch cpu's leakage from efuse in the notifier_call. so the efuse
driver should probe before cpufreq driver.

Signed-off-by: Finley Xiao <[e-mail]>
---
 drivers/nvmem/rockchip-efuse.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Comments

Kevin Hilman Aug. 18, 2016, 6:28 p.m. UTC | #1

Finlye Xiao <[e-mail]> writes:

> From: Finley Xiao <[e-mail]>
>
> We will register a cpufreq notifier for adjusting opp's voltage, and it
> need to fetch cpu's leakage from efuse in the notifier_call. so the efuse
> driver should probe before cpufreq driver.
>
> Signed-off-by: Finley Xiao <[e-mail]>

Why can't this be handled with deferred probling?  initcall ordering is
a can of worms.

Kevin

Heiko Stuebner Aug. 18, 2016, 10:29 p.m. UTC | #2

Am Donnerstag, 18. August 2016, 13:28:58 CEST schrieb Kevin Hilman:
> Finlye Xiao <[e-mail]> writes:
> > From: Finley Xiao <[e-mail]>
> > 
> > We will register a cpufreq notifier for adjusting opp's voltage, and it
> > need to fetch cpu's leakage from efuse in the notifier_call. so the efuse
> > driver should probe before cpufreq driver.
> > 
> > Signed-off-by: Finley Xiao <[e-mail]>
> 
> Why can't this be handled with deferred probling?  initcall ordering is
> a can of worms.

I think the issue is less between efuse and avs driver, but more between avs 
driver and cpufreq. The avs driver aims to modify the opp table and thus wants 
to do that / register the notifier before cpufreq starts.

And as there is no direct connection between cpufreq and the avs driver, 
making cpufreq defer probing is probably not really easy.

Kevin Hilman Aug. 19, 2016, 4:19 p.m. UTC | #3

Heiko Stuebner <[e-mail]> writes:

> Am Donnerstag, 18. August 2016, 13:28:58 CEST schrieb Kevin Hilman:
>> Finlye Xiao <[e-mail]> writes:
>> > From: Finley Xiao <[e-mail]>
>> > 
>> > We will register a cpufreq notifier for adjusting opp's voltage, and it
>> > need to fetch cpu's leakage from efuse in the notifier_call. so the efuse
>> > driver should probe before cpufreq driver.
>> > 
>> > Signed-off-by: Finley Xiao <[e-mail]>
>> 
>> Why can't this be handled with deferred probling?  initcall ordering is
>> a can of worms.
>
> I think the issue is less between efuse and avs driver, but more between avs 
> driver and cpufreq. The avs driver aims to modify the opp table and thus wants 
> to do that / register the notifier before cpufreq starts.
>
> And as there is no direct connection between cpufreq and the avs driver, 
> making cpufreq defer probing is probably not really easy.

Thanks for the explanation.

Sounds like something that belongs in the changelog.

Kevin

Patch

diff --git a/drivers/nvmem/rockchip-efuse.c b/drivers/nvmem/rockchip-efuse.c
index 4d3f391..378993d 100644
--- a/drivers/nvmem/rockchip-efuse.c
+++ b/drivers/nvmem/rockchip-efuse.c
@@ -144,6 +144,13 @@  static struct platform_driver rockchip_efuse_driver = {
 	},
 };
 
-module_platform_driver(rockchip_efuse_driver);
+static int __init rockchip_efuse_module_init(void)
+{
+	return platform_driver_probe(&rockchip_efuse_driver,
+				     rockchip_efuse_probe);
+}
+
+subsys_initcall(rockchip_efuse_module_init);
+
 MODULE_DESCRIPTION("rockchip_efuse driver");
 MODULE_LICENSE("GPL v2");