Message ID | 20240216190113.20341-1-beanhuo@iokpp.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-69219-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:c619:b0:108:e6aa:91d0 with SMTP id hn25csp758099dyb; Fri, 16 Feb 2024 12:05:59 -0800 (PST) X-Forwarded-Encrypted: i=4; AJvYcCU2GwIjjI2MkHKrM+OZn0trdCsf/hfzGiDfnpF9X18DW3eMjGGTdFTQR1e6HF+LEenSBg1Uwm9TQuRz9KuqYSvnvTvBvg== X-Google-Smtp-Source: AGHT+IGg8dl2aAdyLLWdPzhdGY8DSHpIEUYqlLimlKECsBJNvNpXHfxVvN5x8D7th0Caa4UK9pKW X-Received: by 2002:a05:6a20:d04f:b0:19c:a2ef:c45e with SMTP id hv15-20020a056a20d04f00b0019ca2efc45emr6886190pzb.37.1708113958762; Fri, 16 Feb 2024 12:05:58 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1708113958; cv=pass; d=google.com; s=arc-20160816; b=CxaaOzwuWIElEs3tWoD8sxX0se8QDmvLSyj+IUmJrVR/ovrxn7e97GRGMNDjrPQJdS yTUWyFIydJsnu0egVI3s4R8Qnux/+OW+PQTnIA5nOdgA6FLDbmv83jDPl+mlJg/Dgr/0 iwl30CMMCLhtukfaC+c33+vHWwRCTA0vcpDSwNZj5RPMKz7Hl0ebxvE3i8RkLxtOGxFF mG1MaJdBM3wMbjaBWmdFcfGG00YuFwBVsfy6SqEPABrQX36rbB+oF/Ny2F8pYi2hIXlG AN3hzoHTLt016CFtaJ+26Dj3KBgA3DnR7fIlgw0LtRexjXweJ088fEvqMv5LXAwqvDoF ONgg== ARC-Message-Signature: i=3; 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:message-id:date:subject:cc:to :from:dkim-signature:dkim-signature; bh=ulgL/REy0b8uw3Xwq8lpdyFjXWw2k4rZkOpC9L+y7y4=; fh=OSIcLBq8q6AI2k81DbjR1x4O8JOOnKiY3UmyEdL58z4=; b=NHiW/RVOBIs2pZ7hoK358JqP+nGGnnaytGr1TVa5MrnpqCNGJQ77hNAiHSnGDFtibp HJmWABaQDYNCzgVy02w7YXPth9tFByXHvr664YRByDyyWcBTehpfDAF4brZSWBf75V2o cbdkbBMQMZRvH4gVSsXbgvdrXrQaW+qhKNNhQ8Ng4b3OJpHUjbOwJNDi5pUe1h2w896U Y7Z+bbIMdCwqVhqK4mYi3gzWpWDXCLYk4wWToTsyX5qItpLV5TwqUgsy0hIj5r/fsL3X OpGa/f+I16HN572cPIfYSnjW1qKJtc9kk3iiMVHV54IjRlafk6mDIL3fcwtEK4yZnzWw I/iw==; dara=google.com ARC-Authentication-Results: i=3; mx.google.com; dkim=pass header.i=@iokpp.de header.s=strato-dkim-0002 header.b=BA7o0hbZ; dkim=neutral (no key) header.i=@iokpp.de header.s=strato-dkim-0003; arc=pass (i=2 dkim=pass dkdomain=iokpp.de); spf=pass (google.com: domain of linux-kernel+bounces-69219-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-69219-ouuuleilei=gmail.com@vger.kernel.org" Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id b18-20020a056a000cd200b006e0dd734307si396591pfv.157.2024.02.16.12.05.58 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Feb 2024 12:05:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-69219-ouuuleilei=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=@iokpp.de header.s=strato-dkim-0002 header.b=BA7o0hbZ; dkim=neutral (no key) header.i=@iokpp.de header.s=strato-dkim-0003; arc=pass (i=2 dkim=pass dkdomain=iokpp.de); spf=pass (google.com: domain of linux-kernel+bounces-69219-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-69219-ouuuleilei=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 sy.mirrors.kernel.org (Postfix) with ESMTPS id EC791B225D7 for <ouuuleilei@gmail.com>; Fri, 16 Feb 2024 19:01:52 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 349C3135A77; Fri, 16 Feb 2024 19:01:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=iokpp.de header.i=@iokpp.de header.b="BA7o0hbZ"; dkim=permerror (0-bit key) header.d=iokpp.de header.i=@iokpp.de header.b="n8l7omRy" Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [81.169.146.164]) (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 105D51353EF; Fri, 16 Feb 2024 19:01:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=81.169.146.164 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708110096; cv=pass; b=Okbpg/WM7P/9+vZkEx9jwtxlvs4u0DRAWRCC5r0Z/xyhxmoJzdepyzU5efTWU+b/vHCQqkcnDkgA8P+X4IGCXk8b2DxW1DGm1L+FEngj8uhTKTIQkpTqpLgatHaqH6SoHe76aAKWjGAKCW+S+CtYlbKcbk5ZUspUgfOOfVw3S+A= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708110096; c=relaxed/simple; bh=CH2FDE3cYHYzxEu50JesEpNhdv0xF7mLVe/XBnyauJs=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=CpjESvKHj5WLEKoE3fELK6IT6hZWdtOcqyv30I9oEYvRCwiqR9/t3yoorkxLOqh6vEoLLhz3+/2m0Rwq7h3jWl6XEDMHmhzmYh8g02rdA5FEG/go3vYRlgIkEW4Q4fVUHfAz/Yjz+sQ+VoXR+vRH4PI5pjROYBT0vy5oHi4z3ik= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iokpp.de; spf=none smtp.mailfrom=iokpp.de; dkim=pass (2048-bit key) header.d=iokpp.de header.i=@iokpp.de header.b=BA7o0hbZ; dkim=permerror (0-bit key) header.d=iokpp.de header.i=@iokpp.de header.b=n8l7omRy; arc=pass smtp.client-ip=81.169.146.164 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iokpp.de Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=iokpp.de ARC-Seal: i=1; a=rsa-sha256; t=1708110083; cv=none; d=strato.com; s=strato-dkim-0002; b=Y9fxoYfpM8UjXJsHtoSed8CsgJZBCUmbq2OwRinIfC90wUyT/EjbvvaucYsjPbvUfJ WaVCvXbXY785rTPx1A/cq7043uQvyDBvYWGawzKDGmNx0Jhwp1lDxT3DXubzZtsnHKpg mCr5syC79mOukC+zSHzPyMT73xIdQmvFTtbKAiTJJ98REytpL+QljCImrsN/Ana08kdt 9R7t1/0WQhBeb2tLtEjexmJOod2dELo4Wg+U+eYusJeqixJBJnL7hOu+qxaL/LiwIPaS UjkYYABWslMaY0gsJWlXII9okJFqh5FCu8N3rB+lR4OtNTnxAqM82aUoPnXpPvJ/p5mu cqaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1708110083; s=strato-dkim-0002; d=strato.com; h=Message-Id:Date:Subject:Cc:To:From:Cc:Date:From:Subject:Sender; bh=ulgL/REy0b8uw3Xwq8lpdyFjXWw2k4rZkOpC9L+y7y4=; b=Q515GNoPcgbJ16u9MwHLI2t8mIidDd7yzgtF0pN1dRMYpYbAg+96aikQOfd97fL7po 0REFBzX0endps7mOoZbsRuXylHmGRrh5qYS0MGVTTUkKgHHtUwli1CuSYnnXW05I7ZX6 eo6sIHHP/JFw7EE6tLQxgPA/Dqj1wZ/w87qtHkwBaL7z3a5J6X0eyLBXT457+YPSCV0g lHkATv1oaod1MbpGuiJDXLmR4OraeIR6y7HDBn3d/c8f7vvkuDos/iClVMsXDJPlWKQ7 rBTfLGlIY+AaCSFHY1mUvEJ7s8LasB/825s6XERziyW0P+HDyiuSoWv2SM1IzRHCsa1R CvdA== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1708110082; s=strato-dkim-0002; d=iokpp.de; h=Message-Id:Date:Subject:Cc:To:From:Cc:Date:From:Subject:Sender; bh=ulgL/REy0b8uw3Xwq8lpdyFjXWw2k4rZkOpC9L+y7y4=; b=BA7o0hbZHqrE8/4oJWHqYjHckQFIVJkH6b8yDJjJk+ZoiDIjXeZgVBL+Hlygol0sw7 ZC3bFpff/FRgEjLLGnlMF103Oq/AKKA+cZMt7Ckx2bIuOWXvNeoXpRmeSOf2APv5sjkG 0IaZgOeyQFj++UgTJAtU6Bu9KkwB4gl46d4c+7rFXJQS+0TU3ro6exZjD29PnEoeSR+h 5eLYERmDn5bfw3z/czbGCeV1ho8iyHOPG++90qeyn4TIso7Pd6AIwVevOKXdxeMxCwwm XgEsRWgmNFcVahc+MVBB2fClMx6OSfuj0BwG13kcU7bclStMfg+sbKYf0db+rUeCSBtX 8W8w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1708110082; s=strato-dkim-0003; d=iokpp.de; h=Message-Id:Date:Subject:Cc:To:From:Cc:Date:From:Subject:Sender; bh=ulgL/REy0b8uw3Xwq8lpdyFjXWw2k4rZkOpC9L+y7y4=; b=n8l7omRyOQ2jDSD/hAG4Aw0wM+MpGxa3SWFXkpDTNhxWvIE1zZ5pvZKyftK9cEfNVq JeWNEUREtm+6HOHwvaBg== X-RZG-AUTH: ":LmkFe0i9dN8c2t4QQyGBB/NDXvjDB6pBSedrgBzPc9DUyubU4DD2QzemV2tdlNlNRZBXiUw=" Received: from Munilab01-lab.micron.com by smtp.strato.de (RZmta 49.11.2 AUTH) with ESMTPSA id z34ed901GJ1MAwO (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Fri, 16 Feb 2024 20:01:22 +0100 (CET) From: Bean Huo <beanhuo@iokpp.de> To: bhelgaas@google.com, schnelle@linux.ibm.com, sathyanarayanan.kuppuswamy@linux.intel.com Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Bean Huo <beanhuo@micron.com>, stable@vger.kernel.org Subject: [PATCH v2] PCI: Increase maximum PCIe physical function number to 7 for non-ARI devices Date: Fri, 16 Feb 2024 20:01:13 +0100 Message-Id: <20240216190113.20341-1-beanhuo@iokpp.de> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="us-ascii" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791087302472664711 X-GMAIL-MSGID: 1791087302472664711 |
Series |
[v2] PCI: Increase maximum PCIe physical function number to 7 for non-ARI devices
|
|
Commit Message
Bean Huo
Feb. 16, 2024, 7:01 p.m. UTC
From: Bean Huo <beanhuo@micron.com> The PCIe specification allows up to 8 Physical Functions (PFs) per endpoint when ARI (Alternative Routing-ID Interpretation) is not supported. Previously, our implementation erroneously limited the maximum number of PFs to 7 for endpoints without ARI support. This patch corrects the maximum PF count to adhere to the PCIe specification by allowing up to 8 PFs on non-ARI endpoints. This change ensures better compliance with the standard and improves compatibility with devices relying on this specification. The necessity for this adjustment was verified by a thorough review of the "Alternative Routing-ID Interpretation (ARI)" section in the PCIe 3.0 Spec, which first introduced ARI. Fixes: c3df83e01a96 ("PCI: Clean up pci_scan_slot()") Cc: stable@vger.kernel.org Signed-off-by: Bean Huo <beanhuo@micron.com> --- Changelog: v1--v2: 1. Add Fixes tag 2. Modify commit message --- drivers/pci/probe.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Comments
On 2/16/24 11:01 AM, Bean Huo wrote: > From: Bean Huo <beanhuo@micron.com> > > The PCIe specification allows up to 8 Physical Functions (PFs) per endpoint > when ARI (Alternative Routing-ID Interpretation) is not supported. Previously, > our implementation erroneously limited the maximum number of PFs to 7 for > endpoints without ARI support. I would quote specification reference here, like below: As per PCIe specification r6.2, sec titled "Alternative Routing-ID Interpretation (ARI)", up to 8 [fn # 0..7] functions are allowed in an non ARI capable device. It looks like for an ARI capable device the limit is 256. Why not add that check as well? > > This patch corrects the maximum PF count to adhere to the PCIe specification > by allowing up to 8 PFs on non-ARI endpoints. This change ensures better > compliance with the standard and improves compatibility with devices relying > on this specification. > > The necessity for this adjustment was verified by a thorough review of the > "Alternative Routing-ID Interpretation (ARI)" section in the PCIe 3.0 Spec, > which first introduced ARI. I would always use latest PCIe spec for reference. > > Fixes: c3df83e01a96 ("PCI: Clean up pci_scan_slot()") > Cc: stable@vger.kernel.org > Signed-off-by: Bean Huo <beanhuo@micron.com> > --- > Changelog: > v1--v2: > 1. Add Fixes tag > 2. Modify commit message > --- > drivers/pci/probe.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > index ed6b7f48736a..8c3d0f63bc13 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -2630,7 +2630,8 @@ static int next_fn(struct pci_bus *bus, struct pci_dev *dev, int fn) > if (pci_ari_enabled(bus)) > return next_ari_fn(bus, dev, fn); > > - if (fn >= 7) > + /* If EP does not support ARI, the maximum number of functions should be 7 */ > + if (fn > 7) > return -ENODEV; > /* only multifunction devices may have more functions */ > if (dev && !dev->multifunction)
On Fri, 2024-02-16 at 14:26 -0800, Kuppuswamy Sathyanarayanan wrote: > It looks like for an ARI capable device the limit is 256. Why not add > that > check as well? " With ARI, the 16-bit field is interpreted as two fields instead of three: an 8-bit Bus Number and an 8-bit Function Number - the Device Number field is eliminated. This new interpretation enables an ARI Device to support up to 256 Functions [0..255] instead of 8 Functions [0..7]." the above statement on PCIe Spec highlights that since the Function Number field in an ARI-enabled device is 8 bits, it inherently supports numbering from 0 to 255. Thus, there's no need for additional checks to limit the function number to this range; the 8-bit size of the field naturally imposes this limit. This efficient use of the available address space aligns with the goals of ARI to enhance device functionality within the PCIe specification. Kind regards, Bean
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index ed6b7f48736a..8c3d0f63bc13 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -2630,7 +2630,8 @@ static int next_fn(struct pci_bus *bus, struct pci_dev *dev, int fn) if (pci_ari_enabled(bus)) return next_ari_fn(bus, dev, fn); - if (fn >= 7) + /* If EP does not support ARI, the maximum number of functions should be 7 */ + if (fn > 7) return -ENODEV; /* only multifunction devices may have more functions */ if (dev && !dev->multifunction)