Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp5235479rdb; Sat, 30 Dec 2023 11:30:37 -0800 (PST) X-Google-Smtp-Source: AGHT+IEp7SXjXG66/IzFQmSegKt9Tb8f8/EwWvHh8KEIUSR92WDLseY7DvhZiHKkodAI55Z00NKs X-Received: by 2002:a05:6a20:6525:b0:195:d2c:e166 with SMTP id n37-20020a056a20652500b001950d2ce166mr13369565pzg.118.1703964637055; Sat, 30 Dec 2023 11:30:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703964637; cv=none; d=google.com; s=arc-20160816; b=YeoEcXYKYo7Se+14HbdpSV1e216D/V5W/5zwqsAcjEjFD63/2QMTLaWAr0qYNhEqTW 3IKNQ1Nbxeup9lb/GFjSgTXMatbpww3kdidNtfjulBMx6XUmJSdGr+6+MP16KYeCUUjk wmeXP64hxPH+gbZzO9U0mtoiwccYB/02Uqw+ByKjVGU1LHU6bw0dzqMVs3F110YpMwcy 4uMd+T62u1GROFcUXTM5hwzNA7PpNukhlUOwHpc0MvtHucu/c8YvJVr2+C374Ls/tIR/ IqYj3D3iOGopOUrgz6+B8+Jh4CyKUI+hl6cEuTOVRNlNKAnuxwlA6vlxezzr/DxCjaKf bZDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:references:message-id:subject:cc:to:from:date; bh=OOmMM6T4de0bmUFjleXQpxVgJ/CWKhitkAFdmYlzg5s=; fh=XjlWRknf/6Q700T60yrQwGDm4VYbp8Ji6vI7Gcejp0k=; b=F4x/lUnWoMbk3qcmS+2f9T/jKDPqMtp67t3bMDzdXKiauV964lfy0oEIEdQw3Qc754 /Ola1RKDRF/1d1rANtZfQ7eNfX5o8DCVN5oZ0i7R9u//Ke8N6cfSfJ5RqCHMB9XBK42v X1KjDz9f7DPzCeiWguHFO/5koou2mv7yWrezraZbUWOTqZjCTDFWKD90dt8RAsB0i9kU hman61HK5A79OtebA5FP6AY8t3RJDXm+DB8GgT9jFioe0/oo5hktGANvsRkY+TF1SSvZ OnNRlg5+8NARHsWHLf7NtaCT2bdoclLqKBT9W1Btc8QvUykZ92htxpHV5L6gKv5U/Xl+ Qeng== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-13576-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13576-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id g12-20020a056a0023cc00b006d9f3b55cfbsi7297447pfc.97.2023.12.30.11.30.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Dec 2023 11:30:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-13576-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-13576-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13576-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 sv.mirrors.kernel.org (Postfix) with ESMTPS id CDC00283D05 for ; Sat, 30 Dec 2023 19:30:21 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A4A6EC13C; Sat, 30 Dec 2023 19:30:11 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from bmailout3.hostsharing.net (bmailout3.hostsharing.net [176.9.242.62]) (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 7472FBE4E; Sat, 30 Dec 2023 19:30:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=wunner.de Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=h08.hostsharing.net Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by bmailout3.hostsharing.net (Postfix) with ESMTPS id 0065D100D943F; Sat, 30 Dec 2023 20:30:01 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id A79A3517AC; Sat, 30 Dec 2023 20:30:00 +0100 (CET) Date: Sat, 30 Dec 2023 20:30:00 +0100 From: Lukas Wunner To: Ilpo =?iso-8859-1?Q?J=E4rvinen?= Cc: linux-pci@vger.kernel.org, Bjorn Helgaas , Lorenzo Pieralisi , Rob Herring , Krzysztof Wilczy??ski , Alexandru Gagniuc , Krishna chaitanya chundru , Srinivas Pandruvada , "Rafael J . Wysocki" , linux-pm@vger.kernel.org, Bjorn Helgaas , linux-kernel@vger.kernel.org, Alex Deucher , Daniel Lezcano , Amit Kucheria , Zhang Rui Subject: Re: [PATCH v3 05/10] PCI: Store all PCIe Supported Link Speeds Message-ID: <20231230193000.GA11331@wunner.de> References: <20230929115723.7864-1-ilpo.jarvinen@linux.intel.com> <20230929115723.7864-6-ilpo.jarvinen@linux.intel.com> <20231230114549.GB12257@wunner.de> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20231230114549.GB12257@wunner.de> User-Agent: Mutt/1.10.1 (2018-07-13) On Sat, Dec 30, 2023 at 12:45:49PM +0100, Lukas Wunner wrote: > On Fri, Sep 29, 2023 at 02:57:18PM +0300, Ilpo J?rvinen wrote: > > struct pci_bus stores max_bus_speed. Implementation Note in PCIe r6.0.1 > > sec 7.5.3.18, however, recommends determining supported Link Speeds > > using the Supported Link Speeds Vector in the Link Capabilities 2 > > Register (when available). > > > > Add pcie_bus_speeds into struct pci_bus which caches the Supported Link > > Speeds. The value is taken directly from the Supported Link Speeds > > Vector or synthetized from the Max Link Speed in the Link Capabilities > > Register when the Link Capabilities 2 Register is not available. > > Remind me, what's the reason again to cache this and why is > max_bus_speed not sufficient? Is the point that there may be > "gaps" in the supported link speeds, i.e. not every bit below > the maximum supported speed may be set? And you need to skip > over those gaps when throttling to a lower speed? FWIW I went and re-read the internal review I provided on May 18. Turns out I already mentioned back then that gaps aren't permitted: "Per PCIe r6.0.1 sec 8.2.1, the bitfield in the Link Capabilities 2 register is not permitted to contain gaps between maximum supported speed and lowest possible speed (2.5 GT/s Gen1)." > Also, I note that pci_set_bus_speed() doesn't use LNKCAP2. About that, I wrote in May: "Actually, scratch that. pci_set_bus_speed() is fine. Since it's only interested in the *maximum* link speed, reading just LnkCap is correct. LnkCap2 only needs to be read to determine if a certain speed is *supported*. E.g., even though 32 GT/s are supported, perhaps 16 GT/s are not. It's rather pcie_get_speed_cap() which should be changed. There's no need for it to read LnkCap2. The commit which introduced this, 6cf57be0f78e, was misguided and had to be fixed up with f1f90e254e46. It could be simplified to just read LnkCap and return pcie_link_speed[linkcap & PCI_EXP_LNKCAP_SLS]. If the device is a Root Port or Downstream Port, it doesn't even have to do that but could return the cached value in subordinate->max_bus_speed. If you add another attribute to struct pci_bus for the downstream device's maximum speed, the maximum speed for Endpoints and Upstream Ports could be returned directly as well from that attribute." Thanks, Lukas