Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp5042498rdb; Sat, 30 Dec 2023 03:46:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IFTiwot3IfLw45itY00YhK57bLuRO+VAufqQEhDG9c5StfcQczeYRUmm5HJ68z6ObvlPmFo X-Received: by 2002:a17:902:708a:b0:1d3:f02c:e824 with SMTP id z10-20020a170902708a00b001d3f02ce824mr6603419plk.106.1703936779997; Sat, 30 Dec 2023 03:46:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703936779; cv=none; d=google.com; s=arc-20160816; b=fpl4vMFAsxiVSxTGygoNAR0ExjdmWVatMbMgUGwBWxF8IWmIQOre8I7fRDARwAA8p1 25UZR8H8dScgONBG9U8GeN5WHKuWuDpl/p4UY6V0dNBPv7YZzBykxgI8MgkkC/tuuqSO 689sb8IuH1U4iKWCQPdrSf1wkCUuN4+wt4UopNYDqflky3imJuN8sL5lJgusbT30Nri/ xkEHmwGa8T3/xrQYlcheWwBhkgwkbTeZjqhsbQ59HqU31BKyB+tWVHuhylz7LZubqRkN ntFEBDl4CJEQ83rnrOPj4XjlRJocXxvDrCqMpOLf/oVcoCJ7XulIjR5Vjr4a9X4ggD44 m9cw== 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=sM7ZMN6C72CnSamvvgXGg5uZxDndOKs9yN88TKjXpQ0=; fh=XjlWRknf/6Q700T60yrQwGDm4VYbp8Ji6vI7Gcejp0k=; b=a6EdcTTfeRQ66mFWYIYosOmtTlDcH6uQ0KxA5okeLz+w4P3IuKXnm58/o1qol0RY62 Pgjm9mD2vyfxoPDHJ4pAXQQosgWC+s1yMNmR6MW0uLzTSWf9wJrNke7OSZkAXdW45Sg/ Ei9tk8hAl5SaMn25NlXj+hDkSi6cI8pl9qzpT6H179sF3K0w1xpxlpX7aWHLLAbSn2Qs EDsUAwHTklN4aCMAQQ2r1shap7wRXT2qYKt3duVET7awcPk1apOh04PgERGl614HJ+mG 0b+BOib44z4VnsgH3CIJ82gkIRho8n77uNt9y7WrTUjNIiV8cNOOPVJy1HPZoctbUg2N tgxQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-13408-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13408-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id u5-20020a170903124500b001d49ba67cacsi2837075plh.406.2023.12.30.03.46.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Dec 2023 03:46:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-13408-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-13408-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13408-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 sy.mirrors.kernel.org (Postfix) with ESMTPS id B4AFDB2147E for ; Sat, 30 Dec 2023 11:46:13 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 195058487; Sat, 30 Dec 2023 11:46:01 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from bmailout2.hostsharing.net (bmailout2.hostsharing.net [83.223.78.240]) (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 C67A779CD; Sat, 30 Dec 2023 11:45:57 +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 [83.223.95.28]) (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 bmailout2.hostsharing.net (Postfix) with ESMTPS id 0F3BB2800B6C3; Sat, 30 Dec 2023 12:45:50 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 007581AA9C7; Sat, 30 Dec 2023 12:45:49 +0100 (CET) Date: Sat, 30 Dec 2023 12:45:49 +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: <20231230114549.GB12257@wunner.de> References: <20230929115723.7864-1-ilpo.jarvinen@linux.intel.com> <20230929115723.7864-6-ilpo.jarvinen@linux.intel.com> 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: <20230929115723.7864-6-ilpo.jarvinen@linux.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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? Maybe this becomes apparent in a later patch but from a reviewer's perspective starting at patch 1 and working one's way forward through the series, it's a bit puzzling, so an explanation in the commit message would be beneficial. > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c [...] > +static u8 pcie_get_supported_speeds(u32 linkcap, u32 linkcap2) > +{ > + u8 speeds; > + > + speeds = linkcap2 & PCI_EXP_LNKCAP2_SLS; > + if (speeds) > + return speeds; > + > + /* > + * Synthetize supported link speeds from the Max Link Speed in the > + * Link Capabilities Register. > + */ > + speeds = PCI_EXP_LNKCAP2_SLS_2_5GB; > + if ((linkcap & PCI_EXP_LNKCAP_SLS) == PCI_EXP_LNKCAP_SLS_5_0GB) > + speeds |= PCI_EXP_LNKCAP2_SLS_5_0GB; > + return speeds; > +} This seems to duplicate portions of pcie_get_speed_cap(). Can you refactor that function to take advantage of the cached value, i.e. basically return PCIE_LNKCAP2_SLS2SPEED(dev->bus->pcie_bus_speeds)? Also, I note that pci_set_bus_speed() doesn't use LNKCAP2. Presumably that's a historic artefact but maybe it can be converted to use LNKCAP2 as well. Granted, it's not directly related to this series, but always nice to clean up and rationalize the code. Thanks, Lukas