Re: [PATCH 06/14] ARM: pci: Keep pci_common_init() around after init

[Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

On Thu, Feb 7, 2013 at 1:54 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> 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-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 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-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
>>
>> 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