Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1553799pxu; Sat, 12 Dec 2020 17:30:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJz6wsvx8HT7aUe9kTbm2n4bf92PmRqLmsiTj72aFOSZ+Ego6X6edJIvTmheqyzsJxwWKHde X-Received: by 2002:aa7:d6c9:: with SMTP id x9mr2244122edr.96.1607823038580; Sat, 12 Dec 2020 17:30:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607823038; cv=none; d=google.com; s=arc-20160816; b=VdtFsSAldKJ/ipCTLTKoXDN0f9MDpacSG2oLutWkVvqWpQpEftL8+vhApguVECPf5T hXFdvFZ+Bpkq4eShU8VBQvmFvcgk39prcgrMO2t7C57q236TkrhI6vBIfxDDD9WSJ1TO L+mTp4Zi6LYuvSJ2K5li1u8bztTU8QQa3n7QEsooBlSzGZ22Mr24QRIQQdztaODoaPOR ZgwSzfyaA+SG8Ulk1VhAwdS4/EwaUxf0rHLXv5Ju4K6quXBxdlmBGaO0ZOD1gYQSmKRn W/I38Ed1tMGb+NnB/Up9hCu+tkgEY9DMNZAlDg7FtvOtKJ42nvWc/q1F7LSu0iuvfZ6Y 4Q1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=ZvgUGtk2iPiK3NiUtAC7lqFZ6LGPCFfH490WzkYAiFE=; b=yJ1rVp2LINeB6NR8PhcOyGZgBYaUVDpPkqxdStFrsKH9I5V4WeaI4T1o71S7VFswld gDztWKq0pR64A4x3x0Ktvux6rOt0d1ZSRoGCT3AvMSpaZMb8TpA+T5AUXyP+CmktalPQ F3X7h83vprxi5IgcoGc715qm9wRh41P7zfs4hrCd318iXhROGPnCie+nflqHfVgqjCm7 V21v/dIGSbeOPw2uJG8+Zww0WuFg/P+A8jrFOJUnlVMmsMy1gLEaqDckOjLYgZJhFz4M SGaqM91YVJP8DlBg3v2n5TBzCgNZuP5jyAFgudpE8s/y3sx660dFkgKyBcQcx4AG5NFd j2Mw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dp16si8642097ejc.614.2020.12.12.17.30.15; Sat, 12 Dec 2020 17:30:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403911AbgLKUSZ (ORCPT + 99 others); Fri, 11 Dec 2020 15:18:25 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:48294 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388074AbgLKUST (ORCPT ); Fri, 11 Dec 2020 15:18:19 -0500 Received: from 89-77-60-66.dynamic.chello.pl (89.77.60.66) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.530) id 2f2b1a0f38d96bcd; Fri, 11 Dec 2020 21:17:36 +0100 From: "Rafael J. Wysocki" To: Linux PCI Cc: Daniel Scally , LKML , Linux ACPI , Bjorn Helgaas Subject: [PATCH] PCI: ACPI: Fix up ACPI companion lookup for device 0 on the root bus Date: Fri, 11 Dec 2020 21:17:35 +0100 Message-ID: <4673285.9aE2nYKHPr@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki In some cases acpi_pci_find_companion() returns an incorrect device object as the ACPI companion for device 0 on the root bus (bus 0). On the affected systems that device is the PCI interface to the host bridge and the "ACPI companion" returned for it corresponds to a non-PCI device located in the SoC (e.g. a sensor on an I2C bus). As a result of this, the ACPI device object "attached" to PCI device 00:00.0 cannot be used for enumerating the device that is really represented by it which (of course) is problematic. Address that issue by preventing acpi_pci_find_companion() from returning a device object with a valid _HID (which by the spec should not be present uder ACPI device objects corresponding to PCI devices) for PCI device 00:00.0. Link: https://lore.kernel.org/linux-acpi/1409ba0c-1580-dc09-e6fe-a0c9bcda6462@gmail.com/ Reported-by: Daniel Scally Signed-off-by: Rafael J. Wysocki --- drivers/pci/pci-acpi.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) Index: linux-pm/drivers/pci/pci-acpi.c =================================================================== --- linux-pm.orig/drivers/pci/pci-acpi.c +++ linux-pm/drivers/pci/pci-acpi.c @@ -1162,14 +1162,32 @@ void acpi_pci_remove_bus(struct pci_bus static struct acpi_device *acpi_pci_find_companion(struct device *dev) { struct pci_dev *pci_dev = to_pci_dev(dev); + struct acpi_device *adev; bool check_children; u64 addr; check_children = pci_is_bridge(pci_dev); /* Please ref to ACPI spec for the syntax of _ADR */ addr = (PCI_SLOT(pci_dev->devfn) << 16) | PCI_FUNC(pci_dev->devfn); - return acpi_find_child_device(ACPI_COMPANION(dev->parent), addr, + adev = acpi_find_child_device(ACPI_COMPANION(dev->parent), addr, check_children); + /* + * There may be ACPI device objects in the ACPI namespace that are + * children of the device object representing the host bridge, but don't + * represent PCI devices. Both _HID and _ADR may be present for them, + * even though that is against the specification (for example, see + * Section 6.1 of ACPI 6.3), but in many cases the _ADR returns 0 which + * appears to indicate that they should not be taken into consideration + * as potential companions of PCI devices on the root bus. + * + * To catch this special case, disregard the returned device object if + * it has a valid _HID, addr is 0 and the PCI device at hand is on the + * root bus. + */ + if (adev && adev->pnp.type.platform_id && !addr && !pci_dev->bus->parent) + return NULL; + + return adev; } /**