Jarod Wilson reports that ExpressCard hotplug doesn't work on HP ZBook G2.
The problem turns out to be the ACPI-based "slot detection" code called
from pciehp_probe() which uses questionable heuristics based on what ACPI
objects are present for the PCIe port device to figure out whether to
register a hotplug slot for that port.
That code is used if there is at least one PCIe port having an ACPI device
configuration object related to hotplug (such as _EJ0 or _RMV), and the
Thunderbolt port on the ZBook has _RMV. Of course, Thunderbolt and PCIe
native hotplug need not be mutually exclusive (as they aren't on the
ZBook), so that rule is simply incorrect.
Moreover, the ACPI-based "slot detection" check does not add any value if
pciehp_probe() is called at all and the service type of the device object
it has been called for is PCIE_PORT_SERVICE_HP, because PCIe hotplug
services are only registered if the _OSC handshake in acpi_pci_root_add()
allows the kernel to control the PCIe native hotplug feature. No more
checks need to be carried out to decide whether or not to register a native
PCIe hotlug slot in that case.
For the above reasons, make pciehp_probe() check if it has been called for
the right service type and drop the pointless ACPI-based "slot detection"
check from it. Also remove the entire code whose only user is that check
(the entire pciehp_acpi.c file goes away as a result) and drop function
headers related to it from the internal pciehp header file.
Link: http://lkml.kernel.org/r/1431632038-39917-1-git-send-email-jarod@redhat.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=98581
Reported-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jarod Wilson <jarod@redhat.com>
Tested-by: Jarod Wilson <jarod@redhat.com>
Move pci_configure_slot() and related functions from
drivers/pci/hotplug/pcihp_slot to drivers/pci/probe.c.
This is to prepare for doing device configuration during the normal
enumeration process instead of just after hot-add.
No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Fix whitespace, capitalization, and spelling errors. No functional change.
I know "busses" is not an error, but "buses" was more common, so I used it
consistently.
Signed-off-by: Marta Rybczynska <rybczynska@gmail.com> (pci_reset_bridge_secondary_bus())
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add SCLP PCI configure/deconfigure and implement a PCI hotplug
controller (s390_pci_hpc). The hotplug controller creates a slot
for every PCI function in stand-by or configured state. The PCI
functions are named after the PCI function ID (fid). By writing to
the power attribute in /sys/bus/pci/slots/<fid>/power the PCI function
is moved to stand-by or configured state. If moved to the configured
state the device is automatically scanned by the s390 PCI layer.
Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The fakephp driver was scheduled for removal in 2011.
Fakephp presented /sys/bus/pci/slots/.../power files for every PCI
function. Writing "0" to one of these files logically removed the device
from the system. The PCI core now provides the same functionality with
/sys/bus/pci/devices/.../remove.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
As a followup to 71a082efc9, it's conceivable
that some vendors may expose PCI hotplug functionality through both vendor
mechanisms and ACPI. The native mechanism will generally be a superset of
any functionality provided via ACPI, so the acpiphp driver should always
be initialised after any others. Change the link order such that acpiphp
will not be initialised until any other statically linked drivers have had
an opportunity to claim the hardware.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This patch adds a new pci_configure_slot() function that programs the
PCI bus characteristics for a newly-added device. This is based on
code in pciehp_pci.c, but should be generic enough to be used by pciehp,
shpchp, and acpiphp.
The hotplug_params struct and the program_hpp_typeX() functions are based
on the ACPI definitions, but they aren't really ACPI-specific, and there's
no alternate implementation, so I don't see the need to abstract them yet.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Some hardware exposes PCIE slots in such a way that they can be claimed
by either the acpiphp or pciehp driver. pciehp is the preferred driver
if the firmware allows the OS to claim control via the _OSC method so
should be loaded first - if it fails to bind (either due to a missing
_OSC method or the firmware refusing to hand off control) then we can
fall back to acpiphp or a vendor-specific driver.
This patch simply changes the link order to ensure that pciehp will be
initialised before acpiphp if both are statically built into the kernel.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
There is a problem that some non hot-pluggable PCIe slots are detected
as hot-pluggable by pciehp on some platforms. The immediate cause of
this problem is that hot-plug capable bit in the Slot Capabilities
register is set even for non hot-pluggable slots on those platforms.
It seems a BIOS/hardware problem, but we need workaround about that.
Some of those platforms define hot-pluggable PCIe slots on ACPI
namespace properly, while hot-plug capable bit in the Slot
Capabilities register is set improperly. So using ACPI namespace
information in pciehp to detect PCIe hot-pluggable slots would be a
workaround.
This patch adds 'pciehp_detect_mode' module option. When 'acpi' is
specified, pciehp uses ACPI namespace information to detect PCIe
hot-pluggable slots.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Currently, fakephp will claim all devices; we really only want it
to claim those not in slots.
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Modify the acpiphp driver to use the ACPI dock driver for dock
notifications. Only load the acpiphp driver if we find we have pci dock
devices.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
shpchprm_acpi.c and pciehprm_acpi.c are nearly identical. In addition,
there are functions in both these files that are also in acpiphp_glue.c.
This patch will remove duplicate functions from shpchp, pciehp, and
acpiphp and move this functionality to pci_hotplug, as it is not
hardware specific. Get rid of shpchprm* and pciehprm* files since they
are no longer needed. shpchprm_nonacpi.c and pciehprm_nonacpi.c are
identical, as well as shpchprm_legacy.c and can be replaced with a
macro.
This patch also changes acpiphp to use the common hpp code.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
These patches add generic dock event handling to acpiphp. If there are
pci devices that need to be inserted/removed after the dock event, the
event notification will be handed down to the normal pci hotplug event
handler in acpiphp so that new bridges/devices can be enumerated.
Because some dock stations do not have pci bridges or pci devices that
need to be inserted after a dock, acpiphp will remain loaded to handle
dock events even if no hotpluggable pci slots are discovered.
You probably need to have the pci=assign-busses kernel parameter enabled
to use these patches, and you may not allow ibm_acpi to handle docking
notifications and use this patch.
This patch incorporates feedback provided by many.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Currently, rpaphp registers Virtual I/O slots as hotplug slots. The
only purpose of this registration is to ensure that the VIO subsystem
is notified of new VIO buses during DLPAR adds. Similarly, rpaphp
notifies the VIO subsystem when a VIO bus is DLPAR-removed. The rpaphp
module has special case code to fake results for attributes like power,
adapter status, etc.
The VIO register/unregister functions could just as easily be made from
the DLPAR module. This patch moves the VIO registration calls to the
DLPAR module, and removes the VIO fluff from rpaphp altogether.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is the SGI hotplug driver and additional changes required for
the driver. These modifications include changes to the SN io_init.c code
for memory management, the inclusion of new SAL calls to enable and disable
PCI slots, and a hotplug-style driver.
Signed-off-by: Prarit Bhargava <prarit@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
This patch converts acpiphp to use the generic PCI resource assignment code.
It's quite large, but most of it is deleting the acpiphp_pci and acpiphp_res
files. It's tested on an hp Integrity rx8620 (which won't work without this
patch). Testers with other hardware welcomed.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Rafael J. Wysocki