Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp4087364ioo; Wed, 25 May 2022 14:46:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynNAEm2ykQGKZ/jWoXsY1Jqg0aWXCGdthNqSbot2Q8a1yA9zvayW4f9av3Pay8axO27EpB X-Received: by 2002:a63:fa50:0:b0:3fa:c20d:3f01 with SMTP id g16-20020a63fa50000000b003fac20d3f01mr6927650pgk.419.1653515172786; Wed, 25 May 2022 14:46:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653515172; cv=none; d=google.com; s=arc-20160816; b=XbDvNVfGf1H4SsYUgijAd+VpYUHCetxO2T1hM0XrY8BihwwOYEnzff5yY29RqO8Fjv bCqwXAkrO+jeoGkAmnwX0zEmFkWcj6572fbJrQa1EiYUgsteEBigxwBdjE8/NMkQDPjI TlOngPHxMSmSCrJPf9/oJ4oZC/eNbB7qfXSjsgNBd+ZIbQ+15D+zP77XM8fqNlayulM3 l/kcsRyzWAgA/4V1MabN9i7X6RQIRmj6CqTEMmpH+nFarLOZYGGV7vABLt7qyxtA6RnT Mc2YAwcrmsFq6x/J7Iq4jIrtb7MPoiy0mVe9z9j//5WkDK351mUpJhgrtsXotEF5OpVA e8Sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=6y23SpN7c4c8/IBWbHgVH2b6SE13FAa8+3zts9g7JvI=; b=PEg8lNsfM26eyM6UYtLZvuj66Z8Kwle7FGSRupbUvpjGGff45ngn031kZZMVOzjEmu CTglE3S6SdtjB22RMdpDco7mG0GtQMDdcNu3nEAl5gA13h6Y9frbbfjMD3Yn8/39YOWA eYbOqYnDul8gZ/Fem7qDH8vvtj7OhfBlCX/0EVc7rEEqEp4aAScmNfMZIPcCebp+ekhm HzF1vP71ewUrb6MUXnlI5208R2PVdsZILJvKAFXQSEG7E2AcEETzmquLvm+41gSxMYac vSveTManaVkXHZ1AA3fvwbZ6EuehHhD0/hqsyyX18sg/G2QM/AB56v7Rtv8U+V59oyql tpew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s136-20020a632c8e000000b003dbb2eccf7dsi51159pgs.614.2022.05.25.14.46.01; Wed, 25 May 2022 14:46:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242919AbiEYL17 (ORCPT + 99 others); Wed, 25 May 2022 07:27:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243072AbiEYL1n (ORCPT ); Wed, 25 May 2022 07:27:43 -0400 Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FED8A5004; Wed, 25 May 2022 04:27:34 -0700 (PDT) Received: by mail-yb1-f173.google.com with SMTP id x137so7307895ybg.5; Wed, 25 May 2022 04:27:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6y23SpN7c4c8/IBWbHgVH2b6SE13FAa8+3zts9g7JvI=; b=3OS9EuHmoKEW4OFeUF/RKhubiB73e6qD9o2Iwf5zZi9GlgokjZNpPIEu14MGemf58z ZIa2mI67C5VqIDpHkuZBGmEE0vziF8Eu6VKtQ7T54KuLrvAaUqipZWNBsRuCKBBHieAO Xgvt6l4jO90lp6RVtW6AN1YhW3giAsPv+3kT22Ir12CTA+Ahw/RpO5q2zpYt6moeYznz hYvcmP1W/MQoEwY0GcVdQlrjhE0m5wcSYPSk4xX+HzAQ15T3uxCc7SUeVcnc39J6Yf1u GroDuzeXpxbx9Y7XIhKIGYucxOIvAsAlPhzGyxyIzkapoYU+imjIyuOtMwXy9T9rssP4 qWhA== X-Gm-Message-State: AOAM532tbc/QBucgO4V7SZmtWKsK+dkO2Egmhiht2j45tHNXhO/i0/Td 7+iybtlTzS954cAVC81FAAUmKvcuWeRCv4U7YEK7YSuE X-Received: by 2002:a25:d687:0:b0:64e:3a41:8d5 with SMTP id n129-20020a25d687000000b0064e3a4108d5mr29946641ybg.622.1653478053551; Wed, 25 May 2022 04:27:33 -0700 (PDT) MIME-Version: 1.0 References: <20220517124319.47125-1-yangyicong@hisilicon.com> <20220524205842.GA269611@bhelgaas> In-Reply-To: <20220524205842.GA269611@bhelgaas> From: "Rafael J. Wysocki" Date: Wed, 25 May 2022 13:27:21 +0200 Message-ID: Subject: Re: [RESEND PATCH v5] PCI: Make sure the bus bridge powered on when scanning bus To: Bjorn Helgaas Cc: Yicong Yang , Bjorn Helgaas , Linux PCI , Linux Kernel Mailing List , "Rafael J . Wysocki" , Mika Westerberg , "Rafael J . Wysocki" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 24, 2022 at 10:58 PM Bjorn Helgaas wrote: > > On Tue, May 17, 2022 at 08:43:19PM +0800, Yicong Yang wrote: > > When the bus bridge is runtime suspended, we'll fail to rescan > > the devices through sysfs as we cannot access the configuration > > space correctly when the bridge is in D3hot. > > Is the "D3hot" above a typo? I think devices are supposed to respond > to config accesses when in D3hot. PCIe r6.0, sec 5.3.1.4.1: > > Configuration and Message requests are the only TLPs accepted by a > Function in the D3Hot state. ... > > Functions that are in D3Hot are permitted to be transitioned by > software (writing to their PMCSR PowerState field) to the D0active > state or the D0uninitialized state. Functions that are in D3Hot must > respond to Configuration Space accesses as long as power and clock > are supplied so that they can be returned to D0 by software. That applies to the device itself, though, and not to the bus under it. In general, a bridge in D3hot causes the bus segment on the other side of it to be inaccessible even for config space accesses AFAICS. > > It can be reproduced like: > > > > $ echo 1 > /sys/bus/pci/devices/0000:80:00.0/0000:81:00.1/remove > > $ echo 1 > /sys/bus/pci/devices/0000:80:00.0/pci_bus/0000:81/rescan > > > > 0000:80:00.0 is a Root Port and it is runtime-suspended, so > > 0000:81:00.1 is unreachable after a rescan. > > > > Power up the bridge when scanning the child bus and allow it to > > suspend again by adding pm_runtime_get_sync()/pm_runtime_put() > > in pci_scan_child_bus_extend(). > > > > Cc: Rafael J. Wysocki > > Cc: Mika Westerberg > > Cc: Bjorn Helgaas > > Signed-off-by: Yicong Yang > > Reviewed-by: Rafael J. Wysocki > > --- > > drivers/pci/probe.c | 12 ++++++++++++ > > 1 file changed, 12 insertions(+) > > > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > > index 17a969942d37..b108e72b6586 100644 > > --- a/drivers/pci/probe.c > > +++ b/drivers/pci/probe.c > > @@ -2859,11 +2859,20 @@ static unsigned int pci_scan_child_bus_extend(struct pci_bus *bus, > > unsigned int used_buses, normal_bridges = 0, hotplug_bridges = 0; > > unsigned int start = bus->busn_res.start; > > unsigned int devfn, fn, cmax, max = start; > > + struct pci_dev *bridge = bus->self; > > struct pci_dev *dev; > > int nr_devs; > > > > dev_dbg(&bus->dev, "scanning bus\n"); > > > > + /* > > + * Make sure the bus bridge is powered on, otherwise we may not be > > + * able to scan the devices as we may fail to access the configuration > > + * space of subordinates. > > + */ > > + if (bridge) > > + pm_runtime_get_sync(&bridge->dev); > > + > > /* Go find them, Rover! */ > > for (devfn = 0; devfn < 256; devfn += 8) { > > nr_devs = pci_scan_slot(bus, devfn); > > @@ -2976,6 +2985,9 @@ static unsigned int pci_scan_child_bus_extend(struct pci_bus *bus, > > } > > } > > > > + if (bridge) > > + pm_runtime_put(&bridge->dev); > > + > > /* > > * We've scanned the bus and so we know all about what's on > > * the other side of any bridges that may be on this bus plus > > -- > > 2.24.0 > >