On 08/15/2012 01:42 PM, Bjorn Helgaas wrote: > On Wed, Aug 15, 2012 at 1:28 PM, Thierry Reding > <thierry.reding@xxxxxxxxxxxxxxxxx> wrote: >> On Wed, Aug 15, 2012 at 10:06:27AM -0700, Bjorn Helgaas wrote: >>> On Thu, Jul 26, 2012 at 12:55 PM, Thierry Reding >>> <thierry.reding@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> >>>> --- >>>> Changes in v3: >>>> - none >>>> >>>> Changes in v2: >>>> - use __devinit annotations >>> >>> Your original patch removed __init completely. Here you change it to >>> __devinit. That means we decide whether to discard the function based >>> on whether CONFIG_HOTPLUG is supported. But I think your point is not >>> about hotplug; it's merely that we should be able to scan a PCI bus >>> after init-time. We ought to be able to do a late PCI scan even if >>> hotplug is not supported. >>> >>> Therefore, I'd be inclined to remove __init completely unless you have >>> another reason for preferring __devinit. >> >> I thought __devinit would resolve to nothing if HOTPLUG is defined and >> __init otherwise. That seemed more appropriate. However you are right >> that it is useful to always have it available, so I'm fine with removing >> the annotations altogether. Do you want me to follow up with a patch? Or >> can you just take the first version? I'm not sure if it still applies. > > You're right about how __devinit works. It's just that I don't think > hotplug is actually relevant here. We're trying to make > pci_fixup_irqs() work after init, whether it's because of hotplug or > simply because the arch scans host bridges after init. > > I applied this to my "next" branch. Thanks! Bjorn, I don't see this patch in next-20120907. Did it get dropped for some reason? For the full history, see: http://patchwork.ozlabs.org/patch/173495/. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
