Message ID | 1357764194-12677-7-git-send-email-thierry.reding@avionic-design.de (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Wed, Jan 09, 2013 at 09:43:06PM +0100, Thierry Reding wrote: > When using deferred driver probing, PCI host controller drivers may > actually require this function after the init stage. > > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> > --- > arch/arm/kernel/bios32.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Russell, Can this patch and patch 7 (ARM: pci: Allow passing per-controller private data) of this series be applied for 3.9? Thomas uses them in his Marvell PCIe series as well and it would allow to reduce the complexity of the dependencies. Thierry
Dear Thierry Reding, On Wed, 9 Jan 2013 21:43:06 +0100, Thierry Reding wrote: > When using deferred driver probing, PCI host controller drivers may > actually require this function after the init stage. > > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
On Tue, Feb 05, 2013 at 09:41:48PM +0100, Thierry Reding wrote: > On Wed, Jan 09, 2013 at 09:43:06PM +0100, Thierry Reding wrote: > > When using deferred driver probing, PCI host controller drivers may > > actually require this function after the init stage. > > > > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> > > --- > > arch/arm/kernel/bios32.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > Russell, > > Can this patch and patch 7 (ARM: pci: Allow passing per-controller > private data) of this series be applied for 3.9? Thomas uses them in his > Marvell PCIe series as well and it would allow to reduce the complexity > of the dependencies. It'll need to go into the patch system in that case...
On Wed, Jan 9, 2013 at 9:43 PM, Thierry Reding <thierry.reding@avionic-design.de> wrote: > When using deferred driver probing, PCI host controller drivers may > actually require this function after the init stage. > > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> There seem to be a proliferation of these patches now. Isn't this just papering over the real problem? The discarding of __init sections need to happen *after* all deferred probes are complete, lest we have to remove *all* __init sections from *all* drivers in the kernel, don't we? Yours, Linus Walleij
On Thu, Feb 7, 2013 at 1:54 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wednesday 06 February 2013 17:38:20 Linus Walleij wrote: >> On Wed, Jan 9, 2013 at 9:43 PM, Thierry Reding >> <thierry.reding@avionic-design.de> wrote: >> >> > When using deferred driver probing, PCI host controller drivers may >> > actually require this function after the init stage. >> > >> > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> >> >> There seem to be a proliferation of these patches now. >> >> Isn't this just papering over the real problem? The discarding >> of __init sections need to happen *after* all deferred probes >> are complete, lest we have to remove *all* __init sections from >> *all* drivers in the kernel, don't we? > > No, I think it's not quite that bad. I think the rule is still > just that .probe() functions and anything called from them must > not be __init. They used to be __devinit, which would cause > problems with deferred probing on !HOTPLUG systems but that's > gone in 3.9. > > Thierry's patch is just necessary because pci_common_init used > to be called only from actual __init functions, and not it > gets called from a .probe() function for the first time. Aha OK, then it feels much better now. However it leaves the question of how much __init, __initdata and __initconst we have littering around. Oh, well, we'll see I guess. Thanks, Linus Walleij
On Wed, Feb 06, 2013 at 04:30:41PM +0000, Russell King - ARM Linux wrote: > On Tue, Feb 05, 2013 at 09:41:48PM +0100, Thierry Reding wrote: > > On Wed, Jan 09, 2013 at 09:43:06PM +0100, Thierry Reding wrote: > > > When using deferred driver probing, PCI host controller drivers may > > > actually require this function after the init stage. > > > > > > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> > > > --- > > > arch/arm/kernel/bios32.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > Russell, > > > > Can this patch and patch 7 (ARM: pci: Allow passing per-controller > > private data) of this series be applied for 3.9? Thomas uses them in his > > Marvell PCIe series as well and it would allow to reduce the complexity > > of the dependencies. > > It'll need to go into the patch system in that case... Alright, I'll submit them to the patch system. Thanks. Thierry
On Wednesday 06 February 2013 17:38:20 Linus Walleij wrote: > On Wed, Jan 9, 2013 at 9:43 PM, Thierry Reding > <thierry.reding@avionic-design.de> wrote: > > > When using deferred driver probing, PCI host controller drivers may > > actually require this function after the init stage. > > > > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> > > There seem to be a proliferation of these patches now. > > Isn't this just papering over the real problem? The discarding > of __init sections need to happen *after* all deferred probes > are complete, lest we have to remove *all* __init sections from > *all* drivers in the kernel, don't we? No, I think it's not quite that bad. I think the rule is still just that .probe() functions and anything called from them must not be __init. They used to be __devinit, which would cause problems with deferred probing on !HOTPLUG systems but that's gone in 3.9. Thierry's patch is just necessary because pci_common_init used to be called only from actual __init functions, and not it gets called from a .probe() function for the first time. Arnd
On Wednesday 06 February 2013 18:07:53 Linus Walleij wrote: > However it leaves the question of how much __init, __initdata > and __initconst we have littering around. Oh, well, we'll see > I guess. Actually, kbuild is pretty good at warning around the bugs there. Arnd
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c index 379cf32..da7b0c9 100644 --- a/arch/arm/kernel/bios32.c +++ b/arch/arm/kernel/bios32.c @@ -413,7 +413,7 @@ static int pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) return irq; } -static int __init pcibios_init_resources(int busnr, struct pci_sys_data *sys) +static int pcibios_init_resources(int busnr, struct pci_sys_data *sys) { int ret; struct pci_host_bridge_window *window; @@ -445,7 +445,7 @@ static int __init pcibios_init_resources(int busnr, struct pci_sys_data *sys) return 0; } -static void __init pcibios_init_hw(struct hw_pci *hw, struct list_head *head) +static void pcibios_init_hw(struct hw_pci *hw, struct list_head *head) { struct pci_sys_data *sys = NULL; int ret; @@ -493,7 +493,7 @@ static void __init pcibios_init_hw(struct hw_pci *hw, struct list_head *head) } } -void __init pci_common_init(struct hw_pci *hw) +void pci_common_init(struct hw_pci *hw) { struct pci_sys_data *sys; LIST_HEAD(head);
When using deferred driver probing, PCI host controller drivers may actually require this function after the init stage. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> --- arch/arm/kernel/bios32.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)