| Message ID | 1379320326-13241-10-git-send-email-treding@nvidia.com |
|---|---|
| State | Not Applicable |
| Headers | show |
On Mon, Sep 16, 2013 at 10:32 AM, Thierry Reding <thierry.reding@gmail.com> wrote: > With the driver core now resolving interrupt references at probe time, > it is no longer necessary to force explicit probe ordering using > initcalls. > > Signed-off-by: Thierry Reding <treding@nvidia.com> > --- > Note that there are potentially many more drivers that can be switched > to the generic module_*_driver() interfaces now that interrupts can be > resolved later and deferred probe should be able to handle all the > ordering issues. Let me see if I get this right: so this would be all GPIO/pinctrl drivers which are probed exclusively from the device tree so anything that depends explicitly on CONFIG_OF would be a candidate? I think we have a bit of a problem that some drivers depend only on a certain arch or compiles directly for a certain arch without any specific Kconfig option so that this may be a bit hard to spot, so we should keep an eye out for this once this probing scheme is in place. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Sep 23, 2013 at 09:25:53PM +0200, Linus Walleij wrote: > On Mon, Sep 16, 2013 at 10:32 AM, Thierry Reding > <thierry.reding@gmail.com> wrote: > > With the driver core now resolving interrupt references at probe time, > > it is no longer necessary to force explicit probe ordering using > > initcalls. > > > > Signed-off-by: Thierry Reding <treding@nvidia.com> > > --- > > Note that there are potentially many more drivers that can be switched > > to the generic module_*_driver() interfaces now that interrupts can be > > resolved later and deferred probe should be able to handle all the > > ordering issues. > > Let me see if I get this right: so this would be all GPIO/pinctrl > drivers which are probed exclusively from the device tree > so anything that depends explicitly on CONFIG_OF would > be a candidate? It includes all interrupt providers that are probed from the device tree. I'm not sure exactly what the situation is regarding DT vs non-DT, but if my memory serves me well, with non-DT setups interrupts need to be hard-coded in the board support code. Therefore I don't think the usefulness is limited to drivers that are exclusively probed from device tree, but rather any interrupt providing driver that can be probed from device tree. > I think we have a bit of a problem that some drivers depend > only on a certain arch or compiles directly for a certain arch > without any specific Kconfig option so that this may be a > bit hard to spot, so we should keep an eye out for this > once this probing scheme is in place. Yes, it certainly needs to be decided on a case by case basis. There might be other factors that prevent a driver from being a proper module driver. Thierry
diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c index 9a62672..766e6ef 100644 --- a/drivers/gpio/gpio-tegra.c +++ b/drivers/gpio/gpio-tegra.c @@ -513,12 +513,7 @@ static struct platform_driver tegra_gpio_driver = { }, .probe = tegra_gpio_probe, }; - -static int __init tegra_gpio_init(void) -{ - return platform_driver_register(&tegra_gpio_driver); -} -postcore_initcall(tegra_gpio_init); +module_platform_driver(tegra_gpio_driver); #ifdef CONFIG_DEBUG_FS
With the driver core now resolving interrupt references at probe time, it is no longer necessary to force explicit probe ordering using initcalls. Signed-off-by: Thierry Reding <treding@nvidia.com> --- Note that there are potentially many more drivers that can be switched to the generic module_*_driver() interfaces now that interrupts can be resolved later and deferred probe should be able to handle all the ordering issues. --- drivers/gpio/gpio-tegra.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)