| Message ID | 1431398382-1894-1-git-send-email-joshua.scott@alliedtelesis.co.nz |
|---|---|
| State | New |
| Headers | show |
Dear Joshua Scott, On Tue, 12 May 2015 14:39:42 +1200, Joshua Scott wrote: > The Armada-XP contains a set of GPIO pins. These pins may be used to take > other hardware out of reset. However, the drivers used are currently not > initialized until quite late in the boot process (module_platform_driver). > > This patch replaces the use of module_platform_driver with arch_initcall > in the two drivers that are used to control the GPIO pins. This allows for > drivers using subsys_initcall or later to access to the pins. > > > Signed-off-by: Joshua Scott <joshua.scott@alliedtelesis.co.nz> Thanks for the patch. However, this goes exactly in the opposite direction of commit dd640039e8de4135fd59d4d963487d1239d6fabe ("gpio: mvebu: Remove initcall-based driver initialization"), which switched from postcore_initcall() to module_platform_driver(). Can you describe which drivers registered at subsys_initcall() need those GPIOs? We should be able to get around by using deferred probing. Thanks, Thomas
Hi Thomas, The driver I'm using that requires access to the GPIO pins is one that I've been working on. It doesn't do much, just drives a single reset line to take other hardware out of reset. The hardware that gets taken out of reset includes a few i2c GPIO expanders. The GPIO expanders use the gpio-pca953x.c driver, which uses subsys_initcall. One of the things that we found strange: With the code the way it currently is, we have access to external GPIO expanders before we were able to access the CPUs own built-in GPIO pins. Thank you, Joshua Scott On 12/05/15 19:18, Thomas Petazzoni wrote: > Dear Joshua Scott, > > On Tue, 12 May 2015 14:39:42 +1200, Joshua Scott wrote: >> The Armada-XP contains a set of GPIO pins. These pins may be used to take >> other hardware out of reset. However, the drivers used are currently not >> initialized until quite late in the boot process (module_platform_driver). >> >> This patch replaces the use of module_platform_driver with arch_initcall >> in the two drivers that are used to control the GPIO pins. This allows for >> drivers using subsys_initcall or later to access to the pins. >> >> >> Signed-off-by: Joshua Scott <joshua.scott@alliedtelesis.co.nz> > Thanks for the patch. However, this goes exactly in the opposite > direction of commit dd640039e8de4135fd59d4d963487d1239d6fabe ("gpio: > mvebu: Remove initcall-based driver initialization"), which switched > from postcore_initcall() to module_platform_driver(). > > Can you describe which drivers registered at subsys_initcall() need > those GPIOs? We should be able to get around by using deferred probing. > > Thanks, > > Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Joshua, On Tue, 12 May 2015 22:29:54 +0000, Joshua Scott wrote: > The driver I'm using that requires access to the GPIO pins is one that > I've been working on. It doesn't do much, just drives a single reset > line to take other hardware out of reset. > > The hardware that gets taken out of reset includes a few i2c GPIO > expanders. The GPIO expanders use the gpio-pca953x.c driver, which uses > subsys_initcall. > > One of the things that we found strange: With the code the way it > currently is, we have access to external GPIO expanders before we were > able to access the CPUs own built-in GPIO pins. To be honest, it is not very clear (at least to me) what is the policy of the GPIO subsystem in terms of initialization order. Why is this gpio-pca953x.c driver using subsys_initcall() instead of the regular module_i2c_driver() call, which is for example used by gpio-adnp.c or gpio-adp5588.c. Linus, do you have any comments/suggestions about this? Thanks, Thomas
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c index 1a54205..3dd7e23 100644 --- a/drivers/gpio/gpio-mvebu.c +++ b/drivers/gpio/gpio-mvebu.c @@ -860,4 +860,15 @@ static struct platform_driver mvebu_gpio_driver = { .suspend = mvebu_gpio_suspend, .resume = mvebu_gpio_resume, }; -module_platform_driver(mvebu_gpio_driver); + +static int __init mvebu_gpio_driver_init(void) +{ + return platform_driver_register(&mvebu_gpio_driver); +} +arch_initcall(mvebu_gpio_driver_init); + +static void __exit mvebu_gpio_driver_exit(void) +{ + platform_driver_unregister(&mvebu_gpio_driver); +} +module_exit(mvebu_gpio_driver_exit); diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c index 578db9f..609c732 100644 --- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c +++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c @@ -518,7 +518,17 @@ static struct platform_driver armada_xp_pinctrl_driver = { .resume = armada_xp_pinctrl_resume, }; -module_platform_driver(armada_xp_pinctrl_driver); +static int __init armada_xp_pinctrl_init(void) +{ + return platform_driver_register(&armada_xp_pinctrl_driver); +} +arch_initcall(armada_xp_pinctrl_init); + +static void __exit armada_xp_pinctrl_exit(void) +{ + platform_driver_unregister(&armada_xp_pinctrl_driver); +} +module_exit(armada_xp_pinctrl_exit); MODULE_AUTHOR("Thomas Petazzoni <thomas.petazzoni@free-electrons.com>"); MODULE_DESCRIPTION("Marvell Armada XP pinctrl driver");
The Armada-XP contains a set of GPIO pins. These pins may be used to take other hardware out of reset. However, the drivers used are currently not initialized until quite late in the boot process (module_platform_driver). This patch replaces the use of module_platform_driver with arch_initcall in the two drivers that are used to control the GPIO pins. This allows for drivers using subsys_initcall or later to access to the pins. Signed-off-by: Joshua Scott <joshua.scott@alliedtelesis.co.nz> --- drivers/gpio/gpio-mvebu.c | 13 ++++++++++++- drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 12 +++++++++++- 2 files changed, 23 insertions(+), 2 deletions(-)