Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp194013rwb; Sun, 25 Sep 2022 18:31:28 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7XOd38sW+VYtb+MpzUvBD3ID7VdkYQM6RA8w7Fwyn5rr4yrV6XFAiEmahINoeLgMktXKYF X-Received: by 2002:a63:c111:0:b0:439:103a:6c31 with SMTP id w17-20020a63c111000000b00439103a6c31mr17772369pgf.149.1664155888634; Sun, 25 Sep 2022 18:31:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664155888; cv=none; d=google.com; s=arc-20160816; b=ynJ921OH8xIv5ob11c4nCgemKOW9355LY1uBe/f/BfkOByncCJ5wH2oB+x9ijcx2NS g/RuQfQVAODXlcIR0uwLyMviKO1N2FI6hvvOXQ2pMNzfl/IePUiU/5q8kRiXyWt6tE7J y6b8/FnJ8xr3yJRSY2Ue6GoRkMgpXXv7yzL9nMUo2Nl0HRkOPM83gz/TKkJi4KuqHwa0 6g2QhLguKe3FFLM4LPlhH/mZVt5YYPrnfnGTH4HOhiyFsoviqiUGpVelDcSA58zwHYYU pGtkVfH/rI6bd0v8HE+P4N0Aoxi/4UUiHsW1PJ57mc5jTxr5ZyVp78KscdTlMDkWjOiu /fzg== 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:dkim-signature; bh=CklCJNhkPQ2aUgd9nkzbg3bJriRdeJ5r4RoiGqFwpSs=; b=oXQ+gAeOtSLxQx5pwLS/akmZEsQEmToKnWO2Skym/DO/xTXTAphiEDypZiduTgReRx 2rIEit/4R+ex+P2dGNVnJs01JgRdxCLpj2vReiUnMxYe8Kcml8/bmsSbRlzuw2Q6Nafg ci3y1cL0Fd6HJyNPt17N55ZoS2sl2WepklhrSckHUB/vFgG5tkqm2y5WtDsnZXyQlUh9 OH/p1Fjx21cgy3+QyajVl/ci4jgANiPPjeJCqmNUZq1mmyxa09J5nnnD8jIIILihqVek tDZFRXtn94mWQwinl7xSPQ7yr6BN73Jn20FYb3NzhHt2fnq1fm7XclZjrq2fJGqhjGG/ LAvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nathanrossi.com header.s=google header.b=SBTdUC6x; 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=nathanrossi.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l10-20020a63be0a000000b00438d7ca729bsi16906011pgf.207.2022.09.25.18.31.17; Sun, 25 Sep 2022 18:31:28 -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; dkim=pass header.i=@nathanrossi.com header.s=google header.b=SBTdUC6x; 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=nathanrossi.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230439AbiIZBAF (ORCPT + 99 others); Sun, 25 Sep 2022 21:00:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232860AbiIZBAB (ORCPT ); Sun, 25 Sep 2022 21:00:01 -0400 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 545E3186E7 for ; Sun, 25 Sep 2022 18:00:00 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id y3so11000711ejc.1 for ; Sun, 25 Sep 2022 18:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nathanrossi.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=CklCJNhkPQ2aUgd9nkzbg3bJriRdeJ5r4RoiGqFwpSs=; b=SBTdUC6xAJkx4jFAk3n924DRcJWjY+LWXFvTm0a5UINd3dXzT/24UP/lE4Rei8heQR VdU1hGztX4ztWJ9i1wXohbOkmekPgpIgW9jNsxposcMBpcJsH/9IfBOBz62m68ivBSZJ 9I3+h0gxknquWMsMFnXSNHrKticc8lpEoAJVhlQq13h0adncF4GhwndcwG18747Gel0H Oh7vKnZMLwUPHWp0dL1v6u8U0NWRxvRqjxcsOLsA9ZCYkqYFKYVh3sE9BAXgN4aLMgPW kJKeekraLXNe305tEJmvIFK9n9+EiE0tXoZFAOjy+PM7FwzgmVI9Nk2acpwXbex+EJqO ywVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=CklCJNhkPQ2aUgd9nkzbg3bJriRdeJ5r4RoiGqFwpSs=; b=vF0AbFWqLjnnyMaQzL6aJSasoSmLtmkQ4JbMWkKGSdKAidPIiPpo8d5/EVwv8FUHeV +B6FDewVO/a7fNNAhJRtWmOkzNx0XYB+5g9cyGMep1oTbh1vZBT0tYI9sOirCL0JrTDf 9zE5IYTexLi7ldMIBnBjDFWfrG5KQIcSSjPfMOltJdI6d8dZKE1hO+xYeQvr+Zbc623N uHx9yX7/4A042K8D+okARfRzmYQ+YcdqLyjKs/uWveZBXDnNPLgt5EZ/nKq65qyQDOEu m1P9cVIbBc0FFI2nXL3n6Anhwecnic7tGfIn69wsoyvqbDBALQtlAIFv5s6I6QVtT5du 5tIw== X-Gm-Message-State: ACrzQf2SrahBi0bbsvjAJRAbIrNL8V4vlyexIwqktIiWHdItR2TRdpSB DEZwb980WCW6sjYrQblTTpsQxZioOOy+8gEElzu2XQrqlb4= X-Received: by 2002:a17:907:da9:b0:783:a3b4:2cff with SMTP id go41-20020a1709070da900b00783a3b42cffmr1014418ejc.51.1664153998751; Sun, 25 Sep 2022 17:59:58 -0700 (PDT) MIME-Version: 1.0 References: <20220602065544.2552771-1-nathan@nathanrossi.com> In-Reply-To: <20220602065544.2552771-1-nathan@nathanrossi.com> From: Nathan Rossi Date: Mon, 26 Sep 2022 10:59:47 +1000 Message-ID: Subject: Re: [PATCH] PCI/ASPM: Wait for data link active after retraining To: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Nathan Rossi , Bjorn Helgaas Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 Thu, 2 Jun 2022 at 16:55, Nathan Rossi wrote: > > From: Nathan Rossi > > When retraining the link either the child or the parent device may have > the data link layer state machine of the respective devices move out of > the active state despite the physical link training being completed. > Depending on how long is takes for the devices to return to the active > state, the device may not be ready and any further reads/writes to the > device can fail. > > This issue is present with the pci-mvebu controller paired with a device > supporting ASPM but without advertising the Slot Clock, where during > boot the pcie_aspm_cap_init call would cause common clocks to be made > consistent and then retrain the link. However the data link layer would > not be active before any device initialization (e.g. ASPM capability > queries, BAR configuration) causing improper configuration of the device > without error. > > To ensure the child device is accessible, after the link retraining use > pcie_wait_for_link to perform the associated state checks and any needed > delays. > > Signed-off-by: Nathan Rossi > --- Just pinging this patch, are there any comments or feedback for this change? Thanks, Nathan > drivers/pci/pcie/aspm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c > index a96b7424c9..4b8a1810be 100644 > --- a/drivers/pci/pcie/aspm.c > +++ b/drivers/pci/pcie/aspm.c > @@ -288,7 +288,8 @@ static void pcie_aspm_configure_common_clock(struct pcie_link_state *link) > reg16 &= ~PCI_EXP_LNKCTL_CCC; > pcie_capability_write_word(parent, PCI_EXP_LNKCTL, reg16); > > - if (pcie_retrain_link(link)) > + /* Retrain link and then wait for the link to become active */ > + if (pcie_retrain_link(link) && pcie_wait_for_link(parent, true)) > return; > > /* Training failed. Restore common clock configurations */ > --- > 2.36.1