Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp509159pxb; Thu, 21 Apr 2022 04:43:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJydXNdwtQaGBlFtxs5yuancP60hlRASHsiV7OKwE89DSrTepXOxwq+W/HxEJ9cRSbJ3gbHj X-Received: by 2002:a17:906:3918:b0:6e0:5bbd:bf33 with SMTP id f24-20020a170906391800b006e05bbdbf33mr22135808eje.764.1650541418381; Thu, 21 Apr 2022 04:43:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650541418; cv=none; d=google.com; s=arc-20160816; b=cG0gagrNj6g8swrkRDU2CBICGMcTzRcPMruw7ie9tdICyHTPeGC23Z8lQkFqcLIoLN 4XP7a2TgpbDrGXKUJf9uBUIwNaosFBizVeNIvMaLV5X4RV/cRC3H8gi75GWE8+cdsqHb OcWWje59YiwjHiYJNGReMwmFTVVa5hV6NgXyc38yPmYcXFXDSWD7N97RuRVvM9b+k8lW N1jnl/TAJQKUUqZ9FfWqMFRBTrq1xWAfa8so8cHC+cweBArf5AiextbVuO5fzv6vfRX4 ohwlSxX93PIIQPKuW1/UA11Psi9BbNicHDGE4VXOkU+yj1j+Z4ZtgTzmW4ztCukx2D6P BfWw== 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=N3fPv8pbsvbdnmwuFsfNg5pjCiBB7G4V4ZkZ1LyVVAk=; b=MCRG9zVB+WCelE9O2Z4mKvo4i20FLRqdPZ4Fd9+KOUKA/i9b+RkFJeEdjIvY9pBP7S Zf/MdTB5CV/y0hK5c8Z2CLCWbK0xQe1AldB00VMXito0Sd5TMdQQjPwujd/w8zDlrVi1 OXCB6OpAsFTcYrTcv7XjYgfmGSJAoAylhpn8C/X5Em/anqBilChKcnYM7qJx1lp5aUxV C6DFy3QDIXkCfLwFij0FSTLK5CvxUJDp4r5kPl5Xziw4nz4SNyBEkQIQC8xKahU8T4Xq nmTrqOa4B7eqe4AvfKUJdWQGXi41bbDB7AZz82FxRz7LfMDee2QhhGqPFs0dL4jAsTwt rwsQ== 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 l13-20020a056402254d00b0041d38202363si3967162edb.500.2022.04.21.04.43.13; Thu, 21 Apr 2022 04:43:38 -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 S1380703AbiDTQp5 (ORCPT + 99 others); Wed, 20 Apr 2022 12:45:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351187AbiDTQp4 (ORCPT ); Wed, 20 Apr 2022 12:45:56 -0400 Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E53AB4664D; Wed, 20 Apr 2022 09:43:09 -0700 (PDT) Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-2f19fdba41fso24585827b3.3; Wed, 20 Apr 2022 09:43:09 -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=N3fPv8pbsvbdnmwuFsfNg5pjCiBB7G4V4ZkZ1LyVVAk=; b=WPPNboVxHsC72mWqGrSGIYy+ZCzHVDCSkBb6MObrs6ADUgTYpepaImgSf5nfvlAPFf rQmA6JAQTHX3/PkolKvwYfwMW27tmS34udvJwRyyaamuwXlX6mxFoArQJmEAPfqM9DSm PCmPK0G5fsDRPm7S4iphzzQs0jSLTXSCKnCCmfFLjdPGPSEFIEx2Xx74EslLxhKksCiB +o3eiQKqPZlHI8Uc7ZwbPfkAr79xlFAPxFnEBJGCy+4ewOIsogNCUXYOPkN6DzIjX1cO IL2ynnscfiWSJuzDb1pkIrnbW8mjLE34+0YhvUei9GL/m38t1QaJwUS7n68lF5XFe4Ra N2XQ== X-Gm-Message-State: AOAM531K7izctXOiPOcDxLG3YZWyl09QFyKRiX4/HZ6XWSkmmuoPAfqO 0wEhxAT7I+JytDzk3QKlpoGZ9M7SqTH6cRAIRuu34fG2 X-Received: by 2002:a81:b89:0:b0:2eb:e9e6:470a with SMTP id 131-20020a810b89000000b002ebe9e6470amr22115304ywl.7.1650472989143; Wed, 20 Apr 2022 09:43:09 -0700 (PDT) MIME-Version: 1.0 References: <20220414123736.34150-1-yangyicong@hisilicon.com> <20220420163249.GA1305194@bhelgaas> In-Reply-To: <20220420163249.GA1305194@bhelgaas> From: "Rafael J. Wysocki" Date: Wed, 20 Apr 2022 18:42:58 +0200 Message-ID: Subject: Re: [PATCH v3] PCI: Make sure the bus bridge powered on when scanning bus To: Bjorn Helgaas , Yicong Yang Cc: Bjorn Helgaas , Linux PCI , Linux Kernel Mailing List , Linuxarm , prime.zeng@huawei.com, Mika Westerberg , "Rafael J. Wysocki" , Linux PM 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 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 Wed, Apr 20, 2022 at 6:32 PM Bjorn Helgaas wrote: > > [+cc Rafael, linux-pm, since I'd really like his ack/review] > > On Thu, Apr 14, 2022 at 08:37:36PM +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. > > 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 root port and is runtime suspended and we cannot > > get 0000:81:00.1 after rescan. > > > > Make bridge powered on when scanning the child bus, by adding > > pm_runtime_get_sync()/pm_runtime_put() in pci_scan_child_bus_extend(). > > > > A similar issue is met and solved by > > d963f6512e15 ("PCI: Power on bridges before scanning new devices") > > which rescan the devices through /sys/bus/pci/devices/0000:80:00.0/rescan. > > The callstack is like: > > > > dev_rescan_restore() > > pci_rescan_bus() > > pci_scan_bridge_extend() > > pci_scan_child_bus_extend() /* will wake up the bridge with this patch */ > > > > With this patch the issue is also resolved, so let's remove the calls of > > pm_runtime_*() in pci_scan_bridge_extend(). > > > > Cc: Mika Westerberg > > Cc: Bjorn Helgaas > > Signed-off-by: Yicong Yang > > --- > > Change since v2: > > - just rebase it on v5.18-rc2 > > Link: https://lore.kernel.org/linux-pci/1601029386-4928-1-git-send-email-yangyicong@hisilicon.com/ > > > > Change since v1: > > - use an intermediate variable *bridge as suggested > > - remove the pm_runtime_*() calls in pci_scan_bridge_extend() > > Link: https://lore.kernel.org/linux-pci/1596022223-4765-1-git-send-email-yangyicong@hisilicon.com/ > > > > drivers/pci/probe.c | 21 ++++++++++++--------- > > 1 file changed, 12 insertions(+), 9 deletions(-) > > > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > > index 17a969942d37..2ca6b4b708e3 100644 > > --- a/drivers/pci/probe.c > > +++ b/drivers/pci/probe.c > > @@ -1257,12 +1257,6 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, struct pci_dev *dev, > > u8 fixed_sec, fixed_sub; > > int next_busnr; > > > > - /* > > - * Make sure the bridge is powered on to be able to access config > > - * space of devices below it. > > - */ > > - pm_runtime_get_sync(&dev->dev); I understand why this is added below, but I'm not sure why it is safe to remove it from here. Say the bridge is initially in D3cold and we are accessing its config space below. Why is it not necessary to power it up in that case? > > - > > pci_read_config_dword(dev, PCI_PRIMARY_BUS, &buses); > > primary = buses & 0xFF; > > secondary = (buses >> 8) & 0xFF; > > @@ -1464,8 +1458,6 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, struct pci_dev *dev, > > out: > > pci_write_config_word(dev, PCI_BRIDGE_CONTROL, bctl); > > > > - pm_runtime_put(&dev->dev); > > - > > return max; > > } > > > > @@ -2859,11 +2851,19 @@ 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 *dev; > > + struct pci_dev *dev, *bridge = bus->self; I would initialize the new variable in a separate line. > > 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 +2976,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 > > --