From nobody Fri Dec 19 12:52:23 2025 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.4]) (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 4416F337B9B; Tue, 4 Nov 2025 16:52:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.4 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762275165; cv=none; b=ayHWChF6TPSfK1ZFer4ZeTrPXb35jYtb/LPilWyVip5yjlJNeBAxK9+jB7M7SkrQuTribS6o3h9yHo2ZvcuWDljfK4+7XP5sd/XrAd+GrGJ7nvCzaavTlo052pma6Y9eCZFtGWgOa+QidpkkArrs2S/MhZgveWLnt93SY/hTvhs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762275165; c=relaxed/simple; bh=UGM3UqhdVZKvVG/3QztJmPivgRJeeL1DrnwusZbf3JA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=tQIUAEyxPzwmBH2BfuFuTfz58uhFZ6eK4lWbA3nr9TjETWLZLPb1UWQyBwloD6cw+9C7HySO8Z0Ys5DAqevlAjpPXxJI2VLL0GyIyuSF4sjPrCKXGRdJkWhG0vbo+ElKK/9ZjX3p+3oEXtnW4KbrmhvBCh+Q1/I1fTsB/8hs4rY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=TvhDEKnu; arc=none smtp.client-ip=117.135.210.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="TvhDEKnu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=87 R96FN7pE6DYLNvmJ2874NuhQITlr0644TgHtiYcWs=; b=TvhDEKnuHis89BbcDv o7/U6L8dpdQESbVZttOkMUYg0CcVKpchO/UkhuSU50ULyvmKaSdN6CpJUL+niUqC HXCG/x8tk2Uni8wcY4vrtPzSXXk0aGFVTvt0kjQqpJUE9I3FjujWx6rl9zifl41m RUjY1hgE5GXzuLA04CA5hdz/s= Received: from zhb.. (unknown []) by gzsmtp4 (Coremail) with SMTP id PygvCgDHcqsQLwppjl+qCg--.1966S3; Wed, 05 Nov 2025 00:51:32 +0800 (CST) From: Hans Zhang <18255117159@163.com> To: lpieralisi@kernel.org, kwilczynski@kernel.org, bhelgaas@google.com, helgaas@kernel.org, heiko@sntech.de, mani@kernel.org, yue.wang@Amlogic.com Cc: pali@kernel.org, neil.armstrong@linaro.org, robh@kernel.org, jingoohan1@gmail.com, khilman@baylibre.com, jbrunet@baylibre.com, martin.blumenstingl@googlemail.com, cassel@kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-rockchip@lists.infradead.org, Hans Zhang <18255117159@163.com> Subject: [PATCH v6 1/2] PCI: Configure Root Port MPS during host probing Date: Wed, 5 Nov 2025 00:51:24 +0800 Message-Id: <20251104165125.174168-2-18255117159@163.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20251104165125.174168-1-18255117159@163.com> References: <20251104165125.174168-1-18255117159@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: PygvCgDHcqsQLwppjl+qCg--.1966S3 X-Coremail-Antispam: 1Uf129KBjvJXoW7KFW3Xw15GF4rZw4kJrWDurg_yoW8tryUpa 4jqa1FyFs3WF1fZa1DZ3WY9FyYqas7ArW3KF9akwnY9Fs8XFyDXrWYyFZ5J34kCFWIqrya vFn8try8CFnxZFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0piQVyfUUUUU= X-CM-SenderInfo: rpryjkyvrrlimvzbiqqrwthudrp/1tbiFQ-7o2kKLUUmzwAAsg Content-Type: text/plain; charset="utf-8" Current PCIe initialization logic may leave Root Ports (root bridges) operating with non-optimal Maximum Payload Size (MPS) settings. Existing code in pci_configure_mps() returns early for devices without an upstream bridge (!bridge) which includes Root Ports, so their MPS values remain at firmware/hardware defaults. This fails to utilize the controller's full capabilities, leading to suboptimal data transfer efficiency across the PCIe hierarchy. With this patch, during the host controller probing phase: - When PCIe bus tuning is enabled (not PCIE_BUS_TUNE_OFF), and - The device is a Root Port without an upstream bridge (!bridge), The Root Port's MPS is set to its hardware-supported maximum value (128 << dev->pcie_mpss). Note that this initial maximum MPS setting may be reduced later, during downstream device enumeration, if any downstream device does not suppor the Root Port's maximum MPS. This change ensures Root Ports are properly initialized before downstream devices negotiate MPS, while maintaining backward compatibility via the PCIE_BUS_TUNE_OFF check. Suggested-by: Niklas Cassel Suggested-by: Manivannan Sadhasivam Signed-off-by: Hans Zhang <18255117159@163.com> Tested-by: Shawn Lin --- drivers/pci/probe.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 0ce98e18b5a8..2459def3af9b 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -2196,6 +2196,18 @@ static void pci_configure_mps(struct pci_dev *dev) return; } =20 + /* + * Unless MPS strategy is PCIE_BUS_TUNE_OFF (don't touch MPS at all), + * start off by setting Root Ports' MPS to MPSS. This only applies to + * Root Ports without an upstream bridge (root bridges), as other Root + * Ports will have downstream bridges. Depending on the MPS strategy + * and MPSS of downstream devices, the Root Port's MPS may be + * overridden later. + */ + if (!bridge && pci_pcie_type(dev) =3D=3D PCI_EXP_TYPE_ROOT_PORT && + pcie_bus_config !=3D PCIE_BUS_TUNE_OFF) + pcie_set_mps(dev, 128 << dev->pcie_mpss); + if (!bridge || !pci_is_pcie(bridge)) return; =20 --=20 2.34.1