From patchwork Mon May 18 23:06:16 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 6432511 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 546F99F4DD for ; Mon, 18 May 2015 22:41:03 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5EC7D203AD for ; Mon, 18 May 2015 22:41:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 520082044C for ; Mon, 18 May 2015 22:41:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754283AbbERWk6 (ORCPT ); Mon, 18 May 2015 18:40:58 -0400 Received: from v094114.home.net.pl ([79.96.170.134]:65256 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753375AbbERWk5 (ORCPT ); Mon, 18 May 2015 18:40:57 -0400 Received: from aemg72.neoplus.adsl.tpnet.pl (79.191.58.72) (HELO vostro.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer v0.80) id 47b75331f5d3265d; Tue, 19 May 2015 00:40:55 +0200 From: "Rafael J. Wysocki" To: Jarod Wilson Cc: Bjorn Helgaas , linux-kernel@vger.kernel.org, Len Brown , linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org Subject: Re: [PATCH] pci/hotplug: work-around for missing _RMV on HP ZBook G2 Date: Tue, 19 May 2015 01:06:16 +0200 Message-ID: <1948383.UKjRPomMUp@vostro.rjw.lan> User-Agent: KMail/4.11.5 (Linux/4.0.0+; KDE/4.11.5; x86_64; ; ) In-Reply-To: <555A4F68.1020208@redhat.com> References: <1431632038-39917-1-git-send-email-jarod@redhat.com> <555A1093.40303@redhat.com> <555A4F68.1020208@redhat.com> MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Monday, May 18, 2015 04:45:28 PM Jarod Wilson wrote: > 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. So IMO the bug is that select_detection_mode() assumes that ACPI should be used as the PCIe hotplug detection method if it has found at least one device that looks like an "ACPI hotplug slot" (Thuderbolt breaks that "logic"). To be honest, I'm not sure why we need the pciehp_acpi_slot_detection_check() in pciehp_probe() at all. It doesn't add any value as far as I can say. If pciehp_probe() is called at all, we have registered a PCIe port service and if this is a "hotplug" service, we wouldn't have registered it if the _OSC handshake had not given us contol over native hotplug. So I wonder if the patch below makes any difference. --- drivers/pci/hotplug/pciehp_core.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: linux-pm/drivers/pci/hotplug/pciehp_core.c =================================================================== --- linux-pm.orig/drivers/pci/hotplug/pciehp_core.c +++ linux-pm/drivers/pci/hotplug/pciehp_core.c @@ -248,12 +248,9 @@ static int pciehp_probe(struct pcie_devi struct slot *slot; u8 occupied, poweron; - if (pciehp_force) - dev_info(&dev->device, - "Bypassing BIOS check for pciehp use on %s\n", - pci_name(dev->port)); - else if (pciehp_acpi_slot_detection_check(dev->port)) - goto err_out_none; + /* If this is not a "hotplug" service, we have no business here. */ + if (dev->service != PCIE_PORT_SERVICE_HP) + return -ENODEV; if (!dev->port->subordinate) { /* Can happen if we run out of bus numbers during probe */