| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Commit b566a22c23 ("PCI: disable Bus Master on PCI device shutdown")
used pci_disable_device(), but that doesn't disable Bus Mastering
unconditionally; we allow nested enable/disable calls, and only the
last disable call actually does anything.
This uses pci_clear_master() to unconditionally clear the Bus Master
bit.
Matthew Garrett and Alan Cox said (see LKML link below) that clearing Bus
Master for all PCI devices may lead to unpredictable consequences: some
devices ignores this bit and continue DMA, some of them hang after that or
crash the whole system. But we're already trying to clear Bus Master in
general because of b566a22c23; this merely deals with the cases where
drivers haven't shut down the device correctly.
[bhelgaas: changelog]
Link: https://lkml.org/lkml/2012/6/6/278
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
* pci/misc:
PCI: pciehp: Drop suspend/resume ENTRY messages
PCI: Document MPS parameters pci=pcie_bus_safe, pci=pcie_bus_perf, etc
PCI: Document hpiosize= and hpmemsize= resource reservation parameters
PCI: Use PCI Express Capability accessor
PCI: Introduce accessor to retrieve PCIe Capabilities Register
PCI: Kill pci_is_reassigndev()
|
|
* pci/joe-aspm:
PCI/ASPM: Don't touch ASPM if forcibly disabled
PCI/ASPM: Deallocate upstream link state even if device is not PCIe
|
|
* pci/yinghai-root-bus-hotplug:
PCI: acpiphp: Remove dead code for PCI host bridge hotplug
PCI: acpiphp: Create companion ACPI devices before creating PCI devices
PCI: Remove unused "rc" in virtfn_add_bus()
|
|
Commit 668192b678201d2fff27c "PCI: acpiphp: Move host bridge hotplug
to pci_root.c" has moved PCI host bridge hotplug logic from acpiphp
to pci_root, but there is still PCI host bridge hotplug related
dead code left in acpiphp. So remove those dead code.
Now companion ACPI devices are always created before corresponding
PCI devices. And the ACPI event handle_hotplug_event_bridge() will be
installed only if it has associated PCI device. So remove dead code to
handle bridge hot-adding in function handle_hotplug_event_bridge().
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
With commit 4f535093cf8f6da8c "PCI: Put pci_dev in device tree as
early as possible", companion ACPI devices should be created before
creating corresponding PCI devices, otherwise it will break the ACPI
PCI binding logic.
Without this patch, the /sys/bus/pci/devices/.../firmware_node symlink
is missing after hot-removing and hot-adding a device with acpiphp.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Delete unused variable "rc" to fix build warning in drivers/pci/iov.c
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
In each suspend and resume cycle my laptop prints these messages at
KERN_INFO level:
pciehp 0000:00:1c.1:pcie04: pciehp_suspend ENTRY
pciehp 0000:00:1c.0:pcie04: pciehp_suspend ENTRY
and
pciehp 0000:00:1c.0:pcie04: pciehp_resume ENTRY
pciehp 0000:00:1c.1:pcie04: pciehp_resume ENTRY
Drop these messages, that were probably used to debug the suspend and
resume code, but now serve no purpose.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Don't allocate and track PCIe ASPM state when "pcie_aspm=off" is specified
on the kernel command line.
Based-on-patch-from: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: David Bulkow <david.bulkow@stratus.com>
Acked-by: Myron Stowe <myron.stowe@redhat.com>
|
|
On PCI bus hotplug removal, pcie_aspm_exit_link_state() can potentially
skip parent devices that have link_state allocated. Instead of exiting
early if a given device is not PCIe, check whether or not the device's
parent has link_state allocated. This enables pcie_aspm_exit_link_state()
to properly clean up parent link_state when the last function in a slot
might not be PCIe.
Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Use PCI Express Capability access functions to simplify device
Capabilities Register usages.
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The following commits depend on the 'acpi-scan' material.
|
|
The following commits depend on the 'acpi-pm' material.
|
|
* pci/yinghai-root-bus-hotplug:
PCI: Put pci_dev in device tree as early as possible
PCI: Skip attaching driver in device_add()
PCI: acpiphp: Keep driver loaded even if no slots found
PCI/ACPI: Print info if host bridge notify handler installation fails
PCI: acpiphp: Move host bridge hotplug to pci_root.c
PCI/ACPI: acpiphp: Rename alloc_acpiphp_hp_work() to alloc_acpi_hp_work()
PCI: Make device create/destroy logic symmetric
PCI: Fix reference count leak in pci_dev_present()
PCI: Set pci_dev dev_node early so IOAPIC irq_descs are allocated locally
PCI: Add root bus children dev's res to fail list
PCI: acpiphp: Add is_hotplug_bridge detection
Conflicts:
drivers/pci/pci.h
|
|
* pci/acpi-scan2:
ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() instead
ACPI: update ej_event interface to take acpi_device
ACPI / scan: Add second pass to acpi_bus_trim()
ACPI / scan: Change the implementation of acpi_bus_trim()
ACPI / scan: Drop the second argument of acpi_bus_trim()
ACPI / scan: Drop the second argument of acpi_device_unregister()
ACPI: Remove the ops field from struct acpi_device
ACPI: remove unused acpi_op_bind and acpi_op_unbind
ACPI / scan: Fix check of device_attach() return value.
|
|
* pci/yijing-ari:
PCI: shpchp: Iterate over all devices in slot, not functions 0-7
PCI: sgihp: Iterate over all devices in slot, not functions 0-7
PCI: cpcihp: Iterate over all devices in slot, not functions 0-7
PCI: pciehp: Iterate over all devices in slot, not functions 0-7
PCI: Consolidate "next-function" functions
PCI: Rename pci_enable_ari() to pci_configure_ari()
PCI: Enable ARI if dev and upstream bridge support it; disable otherwise
|
|
The following commits depend on the 'acpi-scan' material.
|
|
Since acpi_bus_trim() cannot fail, change its definition to a void
function, so that its callers don't check the return value in vain
and update the callers.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
|
|
We want to put pci_dev structs in the device tree as soon as possible so
for_each_pci_dev() iteration will not miss them, but driver attachment
needs to be delayed until after pci_assign_unassigned_resources() to make
sure all devices have resources assigned first.
This patch moves device registering from pci_bus_add_devices() to
pci_device_add(), which happens earlier, leaving driver attachment in
pci_bus_add_devices().
It also removes unattached child bus handling in pci_bus_add_devices().
That's not needed because child bus via pci_add_new_bus() is already
in parent bus children list.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
We want to add PCI devices to the device tree as early as possible but
delay attaching drivers.
device_add() adds a device to the device hierarchy and (via
device_attach()) attaches a matching driver and calls its .probe() method.
We want to separate adding the device to the hierarchy from attaching the
driver.
This patch does that by adding "match_driver" in struct pci_dev. When
false, we return failure from pci_bus_match(), which makes device_attach()
believe there's no matching driver.
Later, we set "match_driver = true" and call device_attach() again, which
now attaches the driver and calls its .probe() method.
[bhelgaas: changelog, explicitly init dev->match_driver,
fold device_attach() call into pci_bus_add_device()]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Could have root bus hot-added later and there may be slots that need
acpiphp.
The result returned by acpiphp_get_num_slots() is meaningless, because
the bridge the slots are under may be added after this function has been
called, so drop acpiphp_get_num_slots() and the code using it.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The acpiphp driver is confusing because it contains partial support for PCI
host bridge hotplug as well as support for hotplug of PCI devices.
This patch moves the host bridge hot-add support to pci_root.c and adds
hot-remove support in pci_root.c.
How to test it: if sci_emu patch is applied, find out root bus number to
ACPI root name mapping from dmesg or /sys. To remove root bus:
echo "\_SB.PCIB 3" > /sys/kernel/debug/acpi/sci_notify
To add back root bus:
echo "\_SB.PCIB 1" > /sys/kernel/debug/acpi/sci_notify
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Will need to use it for PCI root bridge hotplug support, so rename
*acpiphp* to *acpi* and move to osc.c. Also make kacpi_hotplug_wq static
after that.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: Len Brown <lenb@kernel.org>
CC: linux-acpi@vger.kernel.org
|
|
According to device model documentation, the way to create/destroy PCI
devices should be symmetric. The rule is to either use
1) device_register()/device_unregister()
or
2) device_initialize()/device_add()/device_del()/put_device().
So change PCI core logic to follow the rule and get rid of the redundant
pci_dev_get()/pci_dev_put() pair.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Function pci_get_dev_by_id() takes a reference on the pci_dev returned, so
pci_dev_present() should release the corresponding reference.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Otherwise irq_desc for PCI bridge with hot-added IOAPIC may not be
allocated on the local node.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
We can stop trying according to try_number now and do not need to use
root_bus checking as stop sign.
In extreme case we could need to reallocate resource for device just
under root bus. For PCI root bus hot-add, we need to retry to assign
resources to PCI devices just under pci root bus.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
When system support hotplug bridge with children hotplug slots, we need
to make sure that parent bridge get preallocated resource so later when
device is plugged into children slot, those children devices will get
resource allocated.
We do not meet this problem, because for PCIe hotplug card, when acpiphp
is used, pci_scan_bridge will set that for us when detect hotplug bit in
slot cap.
Reported-and-tested-by: Jason Baron <jbaron@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jason Baron <jbaron@redhat.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm into pci/acpi-scan2
* 'acpi-scan' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() instead
ACPI: update ej_event interface to take acpi_device
ACPI / scan: Add second pass to acpi_bus_trim()
ACPI / scan: Change the implementation of acpi_bus_trim()
ACPI / scan: Drop the second argument of acpi_bus_trim()
ACPI / scan: Drop the second argument of acpi_device_unregister()
ACPI: Remove the ops field from struct acpi_device
ACPI: remove unused acpi_op_bind and acpi_op_unbind
ACPI / scan: Fix check of device_attach() return value.
|
|
Iterate through devices in a slot by using the upstream bridge's
"bus->devices" list instead of assuming they are functions 0-7. It's
possible there are several slots on the same pci_bus, so restrict it to
only devices matching this slot's device number.
ARI (which allows functions 0-255) is a PCIe-only feature, and this is
a PCI hotplug driver, so we shouldn't find anything other than functions
0-7, but it's better to iterate the same way as other hotplug drivers.
[bhelgaas: changelog, check PCI_SLOT, fix shpchp_unconfigure_device()]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Iterate through devices in a slot by using the upstream bridge's
"bus->devices" list instead of assuming they are functions 0-7. It's
possible there are several slots on the same pci_bus, so restrict it to
only devices matching this slot's device number.
ARI (which allows functions 0-255) is a PCIe-only feature, and this is
a PCI hotplug driver, so we shouldn't find anything other than functions
0-7, but it's better to iterate the same way as other hotplug drivers.
[bhelgaas: changelog, check PCI_SLOT, fix disable_slot()]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Iterate through devices in a slot by using the upstream bridge's
"bus->devices" list instead of assuming they are functions 0-7. It's
possible there are several slots on the same pci_bus, so restrict it to
only devices matching this slot's device number.
ARI (which allows functions 0-255) is a PCIe-only feature, and this is
a PCI hotplug driver, so we shouldn't find anything other than functions
0-7, but it's better to iterate the same way as other hotplug drivers.
[bhelgaas: changelog, check PCI_SLOT, fix cpci_unconfigure_slot()]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Currently, we enumerate devices in a slot with pci_scan_slot(), then
iterate through all the devices we found by looking for functions 0-7. But
that's wrong for ARI devices, which may have function numbers up to 255.
This means that when we hot-add an ARI device, pciehp only initializes
functions 0-7, and other functions don't work correctly. Additionally, if
we hot-remove the device, pciehp only removes functions 0-7, leaving stale
pci_dev structures for any other functions.
This patch fixes the problem by iterating over devices in a slot by using
the upstream bridge's "bus->devices" list instead.
[bhelgaas: changelog]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
There are several next_fn functions (no_next_fn, next_trad_fn,
next_ari_fn); consolidate them in next_fn() to simplify the code.
[bhelgaas: make next_fn() static, rework control flow]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
pci_enable_ari() now supports enabling or disabling ARI forwarding. So
rename pci_enable_ari() to pci_configure_ari() for easy understanding.
No functional change.
[bhelgaas: changelog]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
pci_reassigndev_resource_alignment() is the only user of
pci_is_reassigndev(). If we just use pci_specified_resource_alignment()
directly, we only need to call it once instead of twice, and we can get
rid of pci_is_reassigndev() altogether. No functional change.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Currently, we enable ARI in a device's upstream bridge if the bridge and
the device support it. But we never disable ARI, even if the device is
removed and replaced with a device that doesn't support ARI.
This means that if we hot-remove an ARI device and replace it with a
non-ARI multi-function device, we find only function 0 of the new device
because the upstream bridge still has ARI enabled, and next_ari_fn()
only returns function 0 for the new non-ARI device.
This patch disables ARI in the upstream bridge if the device doesn't
support ARI. See the PCIe spec, r3.0, sec 6.13.
[bhelgaas: changelog, function comment]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The new function pci_enable_msi_block_auto() tries to allocate
maximum possible number of MSIs up to the number the device
supports. It generalizes a pattern when pci_enable_msi_block()
is contiguously called until it succeeds or fails.
Opposite to pci_enable_msi_block() which takes the number of
MSIs to allocate as a input parameter,
pci_enable_msi_block_auto() could be used by device drivers to
obtain the number of assigned MSIs and the number of MSIs the
device supports.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Matthew Wilcox <willy@linux.intel.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/c3de2419df94a0f95ca1a6f755afc421486455e6.1353324359.git.agordeev@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras into perf/core
Use perf/event tracing to report PCI Express advanced errors, by
Tony Luck.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI updates from Bjorn Helgaas:
"The most important is a fix for a pciehp deadlock that occurs when
unplugging a Thunderbolt adapter. We also applied the same fix to
shpchp, removed CONFIG_EXPERIMENTAL dependencies, fixed a
pcie_aspm=force problem, and fixed a refcount leak.
Details:
- Hotplug
PCI: pciehp: Use per-slot workqueues to avoid deadlock
PCI: shpchp: Make shpchp_wq non-ordered
PCI: shpchp: Handle push button event asynchronously
PCI: shpchp: Use per-slot workqueues to avoid deadlock
- Power management
PCI: Allow pcie_aspm=force even when FADT indicates it is unsupported
- Misc
PCI/AER: pci_get_domain_bus_and_slot() call missing required pci_dev_put()
PCI: remove depends on CONFIG_EXPERIMENTAL"
* tag '3.8-pci-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI: remove depends on CONFIG_EXPERIMENTAL
PCI: Allow pcie_aspm=force even when FADT indicates it is unsupported
PCI: shpchp: Use per-slot workqueues to avoid deadlock
PCI: shpchp: Handle push button event asynchronously
PCI: shpchp: Make shpchp_wq non-ordered
PCI/AER: pci_get_domain_bus_and_slot() call missing required pci_dev_put()
PCI: pciehp: Use per-slot workqueues to avoid deadlock
|
|
The only difference between acpi_bus_scan() and acpi_bus_add() is the
invocation of acpi_update_all_gpes() in the latter which in fact is
unnecessary, because acpi_update_all_gpes() has already been called
by acpi_scan_init() and the way it is implemented guarantees the next
invocations of it to do nothing.
For this reason, drop acpi_bus_add() and make all its callers use
acpi_bus_scan() directly instead of it. Additionally, rearrange the
code in acpi_scan_init() slightly to improve the visibility of the
acpi_update_all_gpes() call in there.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
|
|
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
* pci/rafael-set-root-bridge-handle:
ACPI / PCI: Set root bridge ACPI handle in advance
|
|
Commit 0090def6 (ACPI: Add interface to register/unregister device
to/from power resources) made it possible to indicate to the ACPI
core that if the given device depends on any power resources, then
it should be resumed as soon as all of the power resources required
by it to transition to the D0 power state have been turned on.
Unfortunately, however, this was a mistake, because all devices
depending on power resources should be treated this way (i.e. they
should be resumed when all power resources required by their D0
state have been turned on) and for the majority of those devices
the ACPI core can figure out by itself which (physical) devices
depend on what power resources.
For this reason, replace the code added by commit 0090def6 with a
new, much more straightforward, mechanism that will be used
internally by the ACPI core and remove all references to that code
from kernel subsystems using ACPI.
For the cases when there are (physical) devices that should be
resumed whenever a not directly related ACPI device node goes into
D0 as a result of power resources configuration changes, like in
the SATA case, add two new routines, acpi_dev_pm_add_dependent()
and acpi_dev_pm_remove_dependent(), allowing subsystems to manage
such dependencies. Convert the SATA subsystem to use the new
functions accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
All callers of acpi_bus_trim() pass 1 (true) as the second argument
of it, so remove that argument entirely and change acpi_bus_trim()
to always behave as though it were 1.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
|
|
Right now using pcie_aspm=force will not enable ASPM if the FADT indicates
ASPM is unsupported. However, the semantics of force should probably allow
for this, especially as they did before 3c076351c4 ("PCI: Rework ASPM
disable code")
This patch just skips the clearing of any ASPM setup that the firmware has
carried out on this bus if pcie_aspm=force is being used.
Reference: http://bugs.launchpad.net/bugs/962038
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org
|
|
* pci/yijing-hotplug-workqueues:
PCI: shpchp: Use per-slot workqueues to avoid deadlock
PCI: shpchp: Handle push button event asynchronously
PCI: shpchp: Make shpchp_wq non-ordered
PCI: pciehp: Use per-slot workqueues to avoid deadlock
|
|
When we have an SHPC-capable bridge with a second SHPC-capable bridge
below it, pushing the upstream bridge's attention button causes a
deadlock.
The deadlock happens because we use the shpchp_wq workqueue to run
shpchp_pushbutton_thread(), which uses shpchp_disable_slot() to remove
devices below the upstream bridge. When we remove the downstream bridge,
we call shpc_remove(), the shpchp driver's .remove() method. That calls
flush_workqueue(shpchp_wq), which deadlocks because the
shpchp_pushbutton_thread() work item is still running.
This patch avoids the deadlock by creating a workqueue for every slot
and removing the single shared workqueue.
Here's the call path that leads to the deadlock:
shpchp_queue_pushbutton_work
queue_work(shpchp_wq) # shpchp_pushbutton_thread
...
shpchp_pushbutton_thread
shpchp_disable_slot
remove_board
shpchp_unconfigure_device
pci_stop_and_remove_bus_device
...
shpc_remove # shpchp driver .remove method
hpc_release_ctlr
cleanup_slots
flush_workqueue(shpchp_wq)
This change is based on code inspection, since we don't have hardware
with this topology.
Based-on-patch-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org
|
|
Use non-ordered workqueue for attention button events.
Attention button events on each slot can be handled asynchronously. So
we should use non-ordered workqueue. This patch also removes ordered
workqueue in shpchp as a result.
486b10b9f4 ("PCI: pciehp: Handle push button event asynchronously") made
the same change to pciehp. I split this out from a patch by Yijing Wang
<wangyijing@huawei.com> so we fix one thing at a time and to make the
shpchp history correspond more closely with the pciehp history.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
|
|
The ACPI handles of PCI root bridges need to be known to
acpi_bind_one(), so that it can create the appropriate
"firmware_node" and "physical_node" files for them, but currently
the way it gets to know those handles is not exactly straightforward
(to put it lightly).
This is how it works, roughly:
1. acpi_bus_scan() finds the handle of a PCI root bridge,
creates a struct acpi_device object for it and passes that
object to acpi_pci_root_add().
2. acpi_pci_root_add() creates a struct acpi_pci_root object,
populates its "device" field with its argument's address
(device->handle is the ACPI handle found in step 1).
3. The struct acpi_pci_root object created in step 2 is passed
to pci_acpi_scan_root() and used to get resources that are
passed to pci_create_root_bus().
4. pci_create_root_bus() creates a struct pci_host_bridge object
and passes its "dev" member to device_register().
5. platform_notify(), which for systems with ACPI is set to
acpi_platform_notify(), is called.
So far, so good. Now it starts to be "interesting".
6. acpi_find_bridge_device() is used to find the ACPI handle of
the given device (which is the PCI root bridge) and executes
acpi_pci_find_root_bridge(), among other things, for the
given device object.
7. acpi_pci_find_root_bridge() uses the name (sic!) of the given
device object to extract the segment and bus numbers of the PCI
root bridge and passes them to acpi_get_pci_rootbridge_handle().
8. acpi_get_pci_rootbridge_handle() browses the list of ACPI PCI
root bridges and finds the one that matches the given segment
and bus numbers. Its handle is then used to initialize the
ACPI handle of the PCI root bridge's device object by
acpi_bind_one(). However, this is *exactly* the ACPI handle we
started with in step 1.
Needless to say, this is quite embarassing, but it may be avoided
thanks to commit f3fd0c8 (ACPI: Allow ACPI handles of devices to be
initialized in advance), which makes it possible to initialize the
ACPI handle of a device before passing it to device_register().
Accordingly, add a new __weak routine, pcibios_root_bridge_prepare(),
defaulting to an empty implementation that can be replaced by the
interested architecutres (x86 and ia64 at the moment) with functions
that will set the root bridge's ACPI handle before its dev member is
passed to device_register(). Make both x86 and ia64 provide such
implementations of pcibios_root_bridge_prepare() and remove
acpi_pci_find_root_bridge() and acpi_get_pci_rootbridge_handle() that
aren't necessary any more.
Included is a fix for breakage on systems with non-ACPI PCI host
bridges from Bjorn Helgaas.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
