PCI's final quirks (pci_fixup_final) are currently invoked by
pci_apply_final_quirk() which traverses the platform's list of PCI
devices. The calling mechanism, and to some point the use of the device
list, limits the quirk invocations to a single instance during boot. As
such, hot-plugable devices do not have their associated final quirks
called upon hot-plug events.
This series implements a interim solution to integrate pci_fixup_final
quirks into the various hot-plug event paths[1].
The series basis is
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
-v2: Re-worked PATCH 1/9 based on Bjorn's suggestion:
http://marc.info/?l=linux-pci&m=134074984925361&w=2
There is some more opportunity to clean this up even further
if we re-work the script that gathers initcall data to accept
'dev_dbg()' structured output.
Replaced PATCHes 3/9-8/9 with 3/8-7/8 (I don't know what I
was thinking with the original set).
[1] I intended to come up with a single, uniform, solution that would
satisfy both the boot path and the various hot-plug event paths with
respect to final quirks. From an architectural perspective, the proper
placement for the final quirks is somewhere just prior to when drivers can
probe and attach which would be the device_add path: pci_bus_add_devices
or pci_bus_add device.
I originally started with that approach but eventually realized that there
are issues with moving the quirks into the device_add path with respect to
booting. Using the 'initcall_debug' boot command instrumentation, one
can see that moving the final quirks into the device_add path would cause
the quirks to be called substantially earlier during boot. While there
may be additional issues, two that were especially concerning were that
the final quirks would be called *before* both 'pci_subsys_init' and
'pcibios_assign_resources'.
Calling the quirks prior to resource assignment seems fraught with
potential issues so I started looking into the various hot-plug paths and
quickly noticed asymmetry with respect to PCI device setup between the
boot path and the hot-plug paths.
Currently, the boot path scans the PCI devices, adds the devices, assigns
resources, and then call the final quirks whereas the hot-plug paths scan,
assign resources, and then add the devices which is better sequencing with
respect to the assignment of resources and the addition of devices (i.e.
resource assignment occurs *before* a driver can probe and attach).
All of this suggests that we should change PCI device setup in the boot
path to be more like hot-plug: scan, assign resources, (final fixups,)
then add. While I think that is the correct approach, and something that
we should be addressing, it will require a lot of work. So until that
occurs, this series should serve as a stop-gap solution for the interim.
When the boot path's PCI device setup is addressed we should end up with a
single, uniform, device_add based solution for applying final quirks
after:
o removing 'fs_initcall_sync(pci_apply_final_quirks);',
o removing the global variable 'pci_fixup_final_inited' and all
of its usages,
o renaming, and moving, the 'pci_cache_line_size' related code
currently embedded in 'pci_apply_final_quirks()'.
Note: I do not have a cross-compile environment so I have only tested x86.
---
Myron Stowe (8):
PCI: Integrate 'pci_fixup_final' quirks into hot-plug paths
PCI: Move final fixup quirks from __init to __devinit
x86/PCI: Move final fixup quirks from __init to __devinit
MIPS/PCI: Move final fixup quirks from __init to __devinit
alpha/PCI: Move final fixup quirks from __init to __devinit
PCI: Adjust section annotations of various quirks
PCI: release temporary reference in __nv_msi_ht_cap_quirk()
PCI: Restructure 'pci_do_fixups()'
arch/alpha/kernel/pci.c | 2 -
arch/mips/mti-malta/malta-pci.c | 2 -
arch/mips/pci/ops-tx4927.c | 2 -
arch/mips/txx9/generic/pci.c | 4 +
arch/x86/kernel/quirks.c | 2 -
drivers/pci/bus.c | 4 +
drivers/pci/quirks.c | 107 ++++++++++++++++++++++++++-------------
7 files changed, 81 insertions(+), 42 deletions(-)
--
--
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
