Received: by 2002:a89:48b:0:b0:1f5:f2ab:c469 with SMTP id a11csp1299717lqd; Thu, 25 Apr 2024 11:07:10 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXj1WUU/AUtD/SZ4TZuSEo1wQulwq9TRKDIH9/ryQT9SOMSFRE5gowlIrlMn8hOforaWRHGnBjJmjxftSEll7BEUL00jXGVDH28xrJ4hw== X-Google-Smtp-Source: AGHT+IGDeZ56tIDm0H+Otd/vv2LEd8aF/wRegwgAcbX0HAzsR+7rnQIiqCTScihaPN+G4QEh8hDg X-Received: by 2002:a17:90a:69a1:b0:2a7:a774:ba7f with SMTP id s30-20020a17090a69a100b002a7a774ba7fmr328370pjj.32.1714068430241; Thu, 25 Apr 2024 11:07:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1714068430; cv=pass; d=google.com; s=arc-20160816; b=xCFMzXASo+CFBkYesMqRqp3adE8LNPcFWNLS/ir3tkLJHkox5yMSN6q/ceyOw0dE5Q Z4/VsFrCYxpqzpN3Tfj/AjV2QgA+99fUEiXXxiNjVCi9JX5xgtU27E89h7qOklPNwK6H KSXzfJxsn9wa+2bL+WF5mtMATfdRNKbBgRJsm8v0a+jzuE75GKRznsJF9+PKIvBgUWnK K4xc34d4uLu6Bcx+jgYg5gpyzFGQuT8Zmf80YvW9SJPPG4Ul+8ROay+feTALTAUzqWEd OlYSo9l/4Tnu+E2KR+iFiQUMNbAgNY/ttgH+Hoy6WB4upSvparxqRGbfeoDXMwvr6ekA nZ1A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :message-id:subject:cc:to:from:date:dkim-signature; bh=RPm5x/OVsc4RYeATKR9zOx5oHSFvivnKvLfolm3+NW8=; fh=y4ko6MrJm0kHtLTssp1PAef6ZBr03AaF4j43VUU4wUI=; b=bbv3NFPS2VdZ3NCUHcFGhb+ujdLKCjjYBXMd2Lz9x9i5eSz+/Yi3OeesQkrSqZoG3M 7KQiIMiT/q88VFCS+EJ6sF7X9Gie8nuV/+t8ng0aCNo2X45FtS3lVuUMK5sH9V907v4e AD/TQUCK3BAwSStTIfUxVxZw3zv+Unp2UbQkxQokrtQSvxUMjYMk5ukLXYNeYzqrPz4K 6fKiWjGtp5wwYwY+qJoT2jFw4hzOHk7aWAAoCQelLoprYEXYgA3fT2j3/9nECj4wV35j 0I+s7MyWAwwsgPmvYou6rjETiAqbjGII27GLZM/k2ATHgTjJoVLm1nGdhmgVapve0ofq B4iw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=W7L1yjXF; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-158984-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-158984-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id j3-20020a17090aeb0300b002a24fd29f92si15388009pjz.117.2024.04.25.11.07.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Apr 2024 11:07:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-158984-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=W7L1yjXF; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-158984-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-158984-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id E189DB231CB for ; Thu, 25 Apr 2024 17:56:30 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6F16E14EC68; Thu, 25 Apr 2024 17:56:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="W7L1yjXF" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8F1FC14D6FF; Thu, 25 Apr 2024 17:56:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714067781; cv=none; b=XSowiPiKiWpQWNZk9EslurLFlg7sdz1MET90V3sRey12ByeaIZNzCjkFbzFTYQIQMqdLSx+KKVWJZjlBOMvueEsYeA60sg1/9Lce8blFJkZEKOYfm0DDhBQcsRrdgF0nIMORmy4t2lRu2qI5JdiNMakk7IVdbDjMjpV5udl9mAI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714067781; c=relaxed/simple; bh=LzVZdtoDNDGly+8PBQMcPIG4Y9obGJckn9Ntux3+3YE=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; b=LbcotmbqkuAFD+t0ImgXulGB8dFQ8C2uB99eg3D9KYtalkUnzJtXjdBKFA3GNjg8cKJYoKjyqAaihIURfWdaLFRx0ffsPxyvMsEivhpBGxLJcIVklsK1GQI3TsirkwmKZcuj8OvnEcjrsZD0sDdW85H83KqeU6agFOg/NeFn4Go= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=W7L1yjXF; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id E28E9C113CC; Thu, 25 Apr 2024 17:56:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1714067780; bh=LzVZdtoDNDGly+8PBQMcPIG4Y9obGJckn9Ntux3+3YE=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=W7L1yjXFVr+sUGcyNJGli/Ed2KyJbBOW4PrazHyYXikteDh3zl4z1fztGROA9eKIv kaYdlgXzG58GZNm5aqCYFYWLKmpyvvUOXmi9ERYeWzm7MRLwCDhfFldY5a8C7StoI5 bMt3lTHWWoO+2GxNz73u3NvUmmKa/e+RwPXcrBnY5/QgYtyx0F13BQImqUVe3O4/Ua R2M0esvSdvDMiIH3BOYD3Q7gIXyrRldLBrUb/ZZ+lD/sFJ9k17rQogcfwPBjeJRZTV T5bICW8B92YpQLI220XnOkoAE5RpVB1Vsj9xpv+923bfEbE4DcFpZUbC1Dyn9rhs4w GoPSWJz0w8SXQ== Date: Thu, 25 Apr 2024 12:56:17 -0500 From: Bjorn Helgaas To: Ilpo =?utf-8?B?SsOkcnZpbmVu?= Cc: Bjorn Helgaas , linux-pci@vger.kernel.org, "Maciej W. Rozycki" , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] PCI: Use the correct bit in Link Training not active check Message-ID: <20240425175617.GA536953@bhelgaas> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240423130820.43824-1-ilpo.jarvinen@linux.intel.com> On Tue, Apr 23, 2024 at 04:08:19PM +0300, Ilpo Järvinen wrote: > Two changes were made into link retraining logic independent of each > other. > > The commit e7e39756363a ("PCI/ASPM: Avoid link retraining race") added > check to ensure no Link Training is currently active into > pcie_retrain_link() to address the Implementation Note in PCIe r6.1 sec > 7.5.3.7. At that time pcie_wait_for_retrain() only checked for Link > Training (LT) bit being cleared. > > The commit 680e9c47a229 ("PCI: Add support for polling DLLLA to > pcie_retrain_link()") generalized pcie_wait_for_retrain() into > pcie_wait_for_link_status() which can wait either for LT or Data Link > Layer Link Active (DLLLA) bit with 'use_lt' argument and supporting > waiting for either cleared or set using 'active' argument. > > In the merge commit commit 1abb47390350 ("Merge branch > 'pci/enumeration'"), those two divergent branches converged. The merge > changed LT bit checking added in the commit e7e39756363a ("PCI/ASPM: > Avoid link retraining race") to now wait for completion of any ongoing > Link Training using DLLLA bit being set if 'use_lt' is false. > > When 'use_lt' is false, the pseudo-code steps of what occurs in > pcie_retrain_link(): > > 1. Wait for DLLLA=1 > 2. Trigger link to retrain > 3. Wait for DLLLA=1 > > Step 3 waits for the link to come up from the retraining triggered by > Step 2. As Step 1 is supposed to wait for any ongoing retraining to > end, using DLLLA also for it does not make sense because link training > being active is still indicated using LT bit, not with DLLLA. > > Correct the pcie_wait_for_link_status() parameters in Step 1 to only > wait for LT=0 to ensure there is no ongoing Link Training. > > This only impacts the Target Speed quirk, which is the only case where > waiting for DLLLA bit is used. It currently works in the problematic > case by means of link training getting initiated by hardware repeatedly > and respecting the new link parameters set by the caller, which then > make training succeed and bring the link up, setting DLLLA and causing > pcie_wait_for_link_status() to return success. We are not supposed to > rely on luck and need to make sure that LT transitioned through the > inactive state though before we initiate link training by hand via RL > (Retrain Link) bit. > > Fixes: 1abb47390350 ("Merge branch 'pci/enumeration'") > Signed-off-by: Ilpo Järvinen I applied both of these with minor typo fixes to pci/enumeration for v6.10, thanks! 73cb3a35f94d ("PCI: Wait for Link Training==0 before starting Link retrain") cdc6c4abcb31 ("PCI: Clarify intent of LT wait") We can update if needed based on feedback from Maciej. > --- > > v2: > - Improve commit message > > NOTE: Maciej NAK'ed the v1 of this patch but has since retracted his > NAK. > > Maciej, if possible, could you please test this with your HW? > > --- > drivers/pci/pci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index e5f243dd4288..70b8c87055cb 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -4629,7 +4629,7 @@ int pcie_retrain_link(struct pci_dev *pdev, bool use_lt) > * avoid LTSSM race as recommended in Implementation Note at the > * end of PCIe r6.0.1 sec 7.5.3.7. > */ > - rc = pcie_wait_for_link_status(pdev, use_lt, !use_lt); > + rc = pcie_wait_for_link_status(pdev, true, false); > if (rc) > return rc; > > -- > 2.39.2 >