Messages in this thread | | | Date | Mon, 18 May 2015 16:45:28 -0400 | From | Jarod Wilson <> | Subject | Re: [PATCH] pci/hotplug: work-around for missing _RMV on HP ZBook G2 |
| |
On 5/18/2015 12:17 PM, Jarod Wilson wrote: > On 5/18/2015 10:33 AM, Jarod Wilson wrote: >> On 5/17/2015 8:26 PM, Rafael J. Wysocki wrote: >>> On Saturday, May 16, 2015 09:41:55 AM Bjorn Helgaas wrote: >>>> On Sat, May 16, 2015 at 09:37:50AM -0500, Bjorn Helgaas wrote: >>>>> Hi Jarod, >>>>> >>>>> On Thu, May 14, 2015 at 03:33:58PM -0400, Jarod Wilson wrote: >>>>>> The HP ZBook 15 and 17 Mobile Workstations, generation 2, up to and >>>>>> including at least BIOS revision 01.07, do not have an ACPI _RMV >>>>>> object >>>>>> associated with their expresscard slots, so acpi-based >>>>>> hotplug-capable >>>>>> slot detection fails. If we fall back to pcie-based detection, the >>>>>> systems >>>>>> work just fine, so this uses dmi matching to do that. With luck, a >>>>>> future >>>>>> BIOS will remedy this (I've let someone at HP know about the >>>>>> problem), >>>>>> but for now, just use this for all existing versions. >> ... >>>>> Oh, my goodness. I forgot how terrible this path is. Can anyone >>>>> write a >>>>> simple explanation of how we choose to use acpiphp or pciehp? >>> >>> In theory, that should depend on the _OSC handshake in >>> acpi_pci_root_add(). >>> >>> If the firmware doesn't give us control of the PCIe features, we'll >>> not use >>> pciehp (or at least that's the idea). >>> >>> acpiphp is used if pciehp doesn't claim the device, AFAICS. >> >> [ 4.013326] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM >> ClockPM Segments MSI] >> [ 4.015860] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME >> AER PCIeCapability] >> >> So at a glance, it would appear that pciehp *should* be claiming it, >> right? Something I noted in the bug I filed is that the device ID >> reported there is PNP0A08, and the root_device_id table that associates >> with acpi_pci_root_add() only includes PNP0A03 in it. Is that correct, >> or should 08 also be in there, which might remedy this? (I can test this >> out easily enough). > > Nope, makes no difference, seems those are just two different references > to the same bus, based on a peek at the extracted dsdt: > > Name (_HID, EisaId ("PNP0A08") /* PCI Express Bus */) // _HID: Hardware ID > Name (_CID, EisaId ("PNP0A03") /* PCI Bus */) // _CID: Compatible ID
Ah, I forgot some additional details. pciehp_probe() in drivers/pci/hotplug/pciehp_core.c fails on the pciehp_acpi_slot_detection_check() call for the expresscard slot, which is why the base pciehp doesn't bind. DEVICE_ACPI_HANDLE(&dev->dev) in the slot detection check is winding up with a NULL acpi device.
-- Jarod Wilson jarod@redhat.com
| |