Received: by 10.192.165.148 with SMTP id m20csp2451508imm; Sun, 22 Apr 2018 07:19:46 -0700 (PDT) X-Google-Smtp-Source: AIpwx48ZvM8vxChUQ4MAL8w/T8k7hMYGSOx7dc+UHm7zY3asNGQ2WDEfVibhtmIiYd2ANKMqW9+Q X-Received: by 10.98.90.135 with SMTP id o129mr16837099pfb.38.1524406786393; Sun, 22 Apr 2018 07:19:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524406786; cv=none; d=google.com; s=arc-20160816; b=hC/YKG21Z4AEg+l7KGlnR4wI//OuI3Rt7u5Kbx8YQjIIDi8+Vce1UOFHBFoZT83l4m MUQhHA7lGCeT5tGFk9MIO6yasOAoXrdLl+Bsxz4cO9aBjzuDIzLRvaF8lfUsHE88BdP7 q4H3paVoG1q6VvYjZ1wQiB2axPng82EPj91V1Vxd6FRJkDK+CqW0sLJ9kXUDa10UlTf1 TxbwlhNmC/vr8x7i7gKOP8pl5oscNn5Ukr9iPR2hJs3MmIA6W1udo45mx4BoAR5uuC5M AUf0Z4/aMa6WRXSben7v/6a1aD8HtUbeFLekcGzNvFUOjrJIaz0LoYO4MwJLbl+C+5M7 Xn1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=+IQd6bFh//vrsOwzcvWH2uxJU7Ja8ZiFIb2iyv5E2sU=; b=LxCYbRSxdQe0/iipqI915o+mhN0B+3miR8lJRTS+73DjUssyYBFs0GBfbbs+e/UwiN ZJcX+UImNBFMt31DyRc7lhsA9o89QtDwidbkBoWv3xgJLNsVxjlmevmu7Qu/GXNF9PHY AAZIgf9aoAzCX9VvXQHt9DKdD277Od1Laat8JLLFhR2KyBLtc3f1xGZKiLlGH5HnHVWl YN+nXCu/B5+BfSFRtLj7ht1rHfvHjnM/ch95ggc5K610oNevjIJMfVWTZsjXIw6fOMgo Tu5cXKDt/vuuNTTh5m4ZlqClPO/2nV5JSiKx35q+bXtE3OeyoDMeBpbl0Is/wXvVs6fK e2Iw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d127si8202479pga.201.2018.04.22.07.19.32; Sun, 22 Apr 2018 07:19:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757256AbeDVOS0 (ORCPT + 99 others); Sun, 22 Apr 2018 10:18:26 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:58870 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757227AbeDVOSU (ORCPT ); Sun, 22 Apr 2018 10:18:20 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 79859CF5; Sun, 22 Apr 2018 14:18:19 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mike Lothian , Mika Westerberg , Bjorn Helgaas , "Rafael J. Wysocki" Subject: [PATCH 4.4 36/97] ACPI / hotplug / PCI: Check presence of slot itself in get_slot_status() Date: Sun, 22 Apr 2018 15:53:14 +0200 Message-Id: <20180422135307.356086292@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180422135304.577223025@linuxfoundation.org> References: <20180422135304.577223025@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mika Westerberg commit 13d3047c81505cc0fb9bdae7810676e70523c8bf upstream. Mike Lothian reported that plugging in a USB-C device does not work properly in his Dell Alienware system. This system has an Intel Alpine Ridge Thunderbolt controller providing USB-C functionality. In these systems the USB controller (xHCI) is hotplugged whenever a device is connected to the port using ACPI-based hotplug. The ACPI description of the root port in question is as follows: Device (RP01) { Name (_ADR, 0x001C0000) Device (PXSX) { Name (_ADR, 0x02) Method (_RMV, 0, NotSerialized) { // ... } } Here _ADR 0x02 means device 0, function 2 on the bus under root port (RP01) but that seems to be incorrect because device 0 is the upstream port of the Alpine Ridge PCIe switch and it has no functions other than 0 (the bridge itself). When we get ACPI Notify() to the root port resulting from connecting a USB-C device, Linux tries to read PCI_VENDOR_ID from device 0, function 2 which of course always returns 0xffffffff because there is no such function and we never find the device. In Windows this works fine. Now, since we get ACPI Notify() to the root port and not to the PXSX device we should actually start our scan from there as well and not from the non-existent PXSX device. Fix this by checking presence of the slot itself (function 0) if we fail to do that otherwise. While there use pci_bus_read_dev_vendor_id() in get_slot_status(), which is the recommended way to read Device and Vendor IDs of devices on PCI buses. Link: https://bugzilla.kernel.org/show_bug.cgi?id=198557 Reported-by: Mike Lothian Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Cc: Greg Kroah-Hartman Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/pci/hotplug/acpiphp_glue.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) --- a/drivers/pci/hotplug/acpiphp_glue.c +++ b/drivers/pci/hotplug/acpiphp_glue.c @@ -587,6 +587,7 @@ static unsigned int get_slot_status(stru { unsigned long long sta = 0; struct acpiphp_func *func; + u32 dvid; list_for_each_entry(func, &slot->funcs, sibling) { if (func->flags & FUNC_HAS_STA) { @@ -597,19 +598,27 @@ static unsigned int get_slot_status(stru if (ACPI_SUCCESS(status) && sta) break; } else { - u32 dvid; - - pci_bus_read_config_dword(slot->bus, - PCI_DEVFN(slot->device, - func->function), - PCI_VENDOR_ID, &dvid); - if (dvid != 0xffffffff) { + if (pci_bus_read_dev_vendor_id(slot->bus, + PCI_DEVFN(slot->device, func->function), + &dvid, 0)) { sta = ACPI_STA_ALL; break; } } } + if (!sta) { + /* + * Check for the slot itself since it may be that the + * ACPI slot is a device below PCIe upstream port so in + * that case it may not even be reachable yet. + */ + if (pci_bus_read_dev_vendor_id(slot->bus, + PCI_DEVFN(slot->device, 0), &dvid, 0)) { + sta = ACPI_STA_ALL; + } + } + return (unsigned int)sta; }