Received: by 2002:a05:7208:13ce:b0:7f:395a:35b6 with SMTP id r14csp1284914rbe; Fri, 1 Mar 2024 09:22:59 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUSnQ8k2Y5NVr0g8FAf1LJewLdxZmV45lA+ms8SKPP0OYrfSlY/UDnBrxKZEL8nKEp6T/4fEzdM+sBIUH6QPizVVDu6Swiw3NObjSjRRg== X-Google-Smtp-Source: AGHT+IEOAoKWCCttyWUO2ZyZ5bEI+WyYVelLAeczudt/p6WEG6BOdX3yWdfArT4cx5zZj2JGxXhJ X-Received: by 2002:a05:622a:586:b0:42d:b584:6217 with SMTP id c6-20020a05622a058600b0042db5846217mr2974664qtb.45.1709313779695; Fri, 01 Mar 2024 09:22:59 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709313779; cv=pass; d=google.com; s=arc-20160816; b=dQWLOXXZ6FhbKpuEC35LhNPe18CiM1AjosyA/eQ2yljb5srFmNh997uHH9BCQaAiqA MgJzbkOHoE2AlUHPgCIYBuwArJpn9VUEVk+pXriOFIUGOA8RdGIxXdU5hhikYrwvwVcQ 5VtoijiXCbCUr9qSChQoQvY+tReaMtv5jvJuBHxkzEItYLVnpadD0jPTBvDFLC5ER7WY E2qYiGcwdMM7Lm6pcZWEY8TajYisQUsIR7ZLnAKX3p1gb5rHWZyYi4jQrM7GOAhyX3hk O++vUApzPZXkMJctSxTH+fKoatn3YICqRFgmCeQAemBCN3PSoM2ZDZklTui3d0G0qe0I yIHA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=CLR7U79RIOPX01O4nkyn8XXMoO4eNsDmOAPeuNP+AdU=; fh=guqzLncJoqytDaotPOa31w0yNt73y0PNQnvonF5biEk=; b=h1dNJV32K6dzcO38LuHQ2ea7mwR1wl0JLVJq/KAofCZv3o/XGJCCmZ0hP3wC/aMWNy 8STRtDfVMWiSxs65sXbz56aswp2Tw2UioziVZ57UDFEzMS0kCDi2wsP+eNSiZOfUaKMR EJ6GPodtE/gt2llcHel6ymrEs013gBK/yA4JhYrG4rCenB5iV3Yx5bvYkXfdKU5vLrNC bdyfEmWQY/3dTcfeP4c2qAJenQRAYGu5kp2RozNoqLcpV1i14ee5mez6fxa4J3gk/3aG BBt5y+ucJjkuD7KO4d9K4XAjd/i+/HcyLMj+xf1UymXcbn/RVtca4Ln38U1mTpkssvwz KPZg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-88816-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88816-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id c25-20020a05620a201900b00787ca90244csi3913479qka.775.2024.03.01.09.22.59 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 09:22:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-88816-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-88816-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88816-linux.lists.archive=gmail.com@vger.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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 722031C2324E for ; Fri, 1 Mar 2024 17:22:59 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1F554C2C7; Fri, 1 Mar 2024 17:22:49 +0000 (UTC) Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 910895228; Fri, 1 Mar 2024 17:22:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.133.224.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709313768; cv=none; b=DAu36qoVKZ5L4pwuh0nzrZqrBjbJizhXTYbUmsqsI/AE0GlV+IbHqwdsxH4Ou5qxMsvvSFmuCLUOC29wNlXWEMJ20i0SawQ6PubJXX1FHGb/0F3dU3jdDvCOR81WCcDVjs49aWMTmYJdm19CYZsb0kuFfzc9aqplYqDLCuxGLAA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709313768; c=relaxed/simple; bh=ovQQBQAWHPAsC8cOFrxmlF14GYtzvzGc9A84d8GOGEE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=bLKHHg2jbHjEADW9eoJ97KHJOAhsslM4PtxmM8RCHnbJ0w0RHQmw7C9Kr1gya29Q4AvbMQSSH4KCPvUVl3lnnErhbKDBKvlJXj1v2Z+tGCdR/S3+gYFNZknwNlWk82T4zXNKKERg34WXFRJvnXi6d0RAFWZekQOUMYo3aoGzi5U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk; spf=none smtp.mailfrom=orcam.me.uk; arc=none smtp.client-ip=78.133.224.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id 193D192009C; Fri, 1 Mar 2024 18:22:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 0ABCE92009B; Fri, 1 Mar 2024 17:22:38 +0000 (GMT) Date: Fri, 1 Mar 2024 17:22:37 +0000 (GMT) From: "Maciej W. Rozycki" To: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= cc: Bjorn Helgaas , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] PCI: Use the correct bit in Link Training not active check In-Reply-To: <20240301150641.4037-1-ilpo.jarvinen@linux.intel.com> Message-ID: References: <20240301150641.4037-1-ilpo.jarvinen@linux.intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) 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-Transfer-Encoding: 8BIT On Fri, 1 Mar 2024, Ilpo Järvinen wrote: > Besides Link Training bit, pcie_retrain_link() can also be asked to > wait for Data Link Layer Link Active bit (PCIe r6.1 sec 7.5.3.8) using > 'use_lt' parameter since the merge commit 1abb47390350 ("Merge branch > 'pci/enumeration'"). Nope, it was added with commit 680e9c47a229 ("PCI: Add support for polling DLLLA to pcie_retrain_link()"), before said merge. > pcie_retrain_link() first tries to ensure Link Training is not > currently active (see Implementation Note in PCIe r6.1 sec 7.5.3.7) > which must always check Link Training bit regardless of 'use_lt'. > Correct the pcie_wait_for_link_status() parameters to only wait for > the correct bit to ensure there is no ongoing Link Training. You're talking the PCIe spec here and code is talking a bad device case. > Since waiting for Data Link Layer Link Active bit is only used for the > Target Speed quirk, this only impacts the case when the quirk attempts > to restore speed to higher than 2.5 GT/s (The link is Up at that point > so pcie_retrain_link() will fail). NAK. It's used for both clamping and unclamping and it will break the workaround, because the whole point there is to wait until DLLA has been set. Using LT is not reliable because it will oscillate in the failure case and seeing the bit clear does not mean link has been established. What are you trying to achieve here and what problem is it to fix? Maciej