pinctrl: pinctrl-single.c: init pinctrl single at arch_initcall time

On our arm platform, some modules (e.g. I2C bus driver) will use the pinctrl-single driver to configure the SoC pin, but pinctrl-single driver uses module_init time, that makes some modules initialize ahead the pinctrl-single and fail to register.

This patch promotes the initialization priority of pinctrl-single from module_init time to arch_initcall time.

Signed-off-by Yunlei He <[email protected]>

Signed-off-by Xinwei Kong <[email protected]>

---
 drivers/pinctrl/pinctrl-single.c |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

drivers/pinctrl/pinctrl-single.c +12 -1

index 95dd9cf..4b9e5b9 100644
@@ -2012,7 +2012,18 @@ static struct platform_driver pcs_driver = {
 #endif
 };
 
-module_platform_driver(pcs_driver);
+static int __init pinctrl_single_init(void)
+{
+		return platform_driver_register(&pcs_driver);
+}
+
+static void __exit pinctrl_single_exit(void)
+{
+		platform_driver_unregister(&pcs_driver);
+}
+
+arch_initcall(pinctrl_single_init);
+module_exit(pinctrl_single_exit);
 
 MODULE_AUTHOR("Tony Lindgren <[email protected]>");
 MODULE_DESCRIPTION("One-register-per-pin type device tree based pinctrl

driver");

Signature · 1 line

1.7.9.5

Quoted 7 lines · He YunLei

On our arm platform, some modules (e.g. I2C bus driver) will use the pinctrl-single driver to configure the SoC pin, but pinctrl-single driver uses module_init time, that makes some modules initialize ahead the pinctrl-single and fail to register.

This patch promotes the initialization priority of pinctrl-single from module_init time to arch_initcall time.

This has come up earlier and so far in all cases the problem is that you have custom initcall levels for your other drivers.

Get rid of custom initcall levels for your drivers and the problem goes away. There's no need to init the drivers earlier nowadays. If you have other dependencies then deferred probe helps but should be only needed for a limited number of cases.

We want to initialize things later, not earlier in general. That removes the issues of no proper debug output while booting the kernel.

Regards,

Tony

Quoted 29 lines

Signed-off-by Yunlei He <[email protected]>

Signed-off-by Xinwei Kong <[email protected]>

---
  drivers/pinctrl/pinctrl-single.c |   13 ++++++++++++-
  1 file changed, 12 insertions(+), 1 deletion(-)

drivers/pinctrl/pinctrl-single.c +12 -1

index 95dd9cf..4b9e5b9 100644
@@ -2012,7 +2012,18 @@ static struct platform_driver pcs_driver = {
  #endif
  };
 
-module_platform_driver(pcs_driver);
+static int __init pinctrl_single_init(void)
+{
+		return platform_driver_register(&pcs_driver);
+}
+
+static void __exit pinctrl_single_exit(void)
+{
+		platform_driver_unregister(&pcs_driver);
+}
+
+arch_initcall(pinctrl_single_init);
+module_exit(pinctrl_single_exit);
 

Quoted 6 lines

drivers/pinctrl/pinctrl-single.c +0 -0

  MODULE_AUTHOR("Tony Lindgren <[email protected]>");
  MODULE_DESCRIPTION("One-register-per-pin type device tree based pinctrl

driver");
--
1.7.9.5

.

Thanks for your review and I am really appreciated it, but in our arm platform, we haven't custom initcall levels for other drivers. Although deferred probe helps other drivers to register well, we are also confused for the issues of lots of pin request errors debug output while booting the kernel. Besides, if the number is bigger than the limited number, whether deferred probe can solve this problem.

Quoted 7 lines · He YunLei

Thanks for your review and I am really appreciated it, but in our arm platform, we haven't custom initcall levels for other drivers. Although deferred probe helps other drivers to register well, we are also confused for the issues of lots of pin request errors debug output while booting the kernel. Besides, if the number is bigger than the limited number, whether deferred probe can solve this problem.

OK. Care to provide some examples where this happens on your platform?

Note that we already have pinctrl very early in drivers/Makefile. What are the early users for pinctrl-single in your setup?

Regards,

Tony

.

Quoted 19 lines · Tony Lindgren

Quoted 7 lines · He YunLei

Thanks for your review and I am really appreciated it, but in our arm platform, we haven't custom initcall levels for other drivers. Although deferred probe helps other drivers to register well, we are also confused for the issues of lots of pin request errors debug output while booting the kernel. Besides, if the number is bigger than the limited number, whether deferred probe can solve this problem.

OK. Care to provide some examples where this happens on your platform?

Note that we already have pinctrl very early in drivers/Makefile. What are the early users for pinctrl-single in your setup?

Regards,

Tony

Quoted 2 lines

.

In our platform we use subsys_initcall in I2C, and fs_initcall in PMIC, Both of them are early than pinctrl-single. Although they register well with the aid of deferred probe, it's really confused us that pins request deferred. Why can't we setup pinctrl-single earlier to reduce these messages.