From nobody Fri Dec 19 11:18:22 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: Mahesh Vaidya 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 From nobody Fri Dec 19 11:18:22 2025 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.2]) (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 D3492338916; Tue, 4 Nov 2025 16:52:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762275170; cv=none; b=lsPpzu3Pns7lJ1GNkRZjlWbuetde+cN8Q0JAXd2YKcLxRm+VIBj7gQTBdvQEILJauFW2/ILSP3DfddA8ZN7Dhiz56/GwOakUa2G1+TRO08vIQ1G6iuMM+0eM1Tb8bZjUMA+Xq+9hGbhQ3Xyk+YYzB+12cEW2yykpSzgYhwXYGaM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762275170; c=relaxed/simple; bh=xY9EeZNG6327M7qafePF+MG8xDd3VZN9/Xn/tPbQxWA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=skMSTT8hYhJ4OiF1SV6NA9MgzOeIhQbVU2J49L5N/0Mp4A8jKL4VkVtFS8sngqdHYzXYb7p4vKgQtwegHDgyvcYl++i0dvBPNZiSa4Ce45L5BltS5KZoxJyrcqtcIgZne48CIDHB7Of3YohhwCcrZSeoGxfIFVinRRpSgTk8Jzs= 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=h5fPKUyG; arc=none smtp.client-ip=117.135.210.2 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="h5fPKUyG" 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=HV 6aCZe858sfDxOrV63v3V1QYYmt0i4YMWexhlJ+tbA=; b=h5fPKUyG1CKLVdQyTu mqwmctmn1qQwDOz2tGj7h+Tdo9iuWDESjeCwE7/7dQW/I2oRJRayNtpVq8v7/aPn 4oxCiiIBRQ+sq3x445D2SNWU3f0GYyqQTxEzrO7vZ6yXnA2wa2PfNTfAZbhoNmo8 hqp/h6gfjHeLs9zZ8r2nbHWpo= Received: from zhb.. (unknown []) by gzsmtp4 (Coremail) with SMTP id PygvCgDHcqsQLwppjl+qCg--.1966S4; Wed, 05 Nov 2025 00:51:33 +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 2/2] PCI: dwc: Remove redundant MPS configuration Date: Wed, 5 Nov 2025 00:51:25 +0800 Message-Id: <20251104165125.174168-3-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--.1966S4 X-Coremail-Antispam: 1Uf129KBjvJXoW7KF4xuw4xXFWDJw43WF4xtFb_yoW8Cr1fpF y3WrsakF18Ar45WF4qkan5Cay3tasxCry7JF9Ig34fZFyayFsrJa4ayFWFka4xWrW293WS kr98K3y8A3W5trUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0pEeOJbUUUUU= X-CM-SenderInfo: rpryjkyvrrlimvzbiqqrwthudrp/1tbiFQH7o2kKLUUm0AABsw Content-Type: text/plain; charset="utf-8" The Meson PCIe controller driver manually configures maximum payload size (MPS) through meson_set_max_payload, duplicating functionality now centralized in the PCI core. Deprecating redundant code simplifies the driver and aligns it with the consolidated MPS management strategy, improving long-term maintainability. Signed-off-by: Hans Zhang <18255117159@163.com> Tested-by: Mahesh Vaidya --- drivers/pci/controller/dwc/pci-meson.c | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controlle= r/dwc/pci-meson.c index 787469d1b396..3d12e1a9bb0c 100644 --- a/drivers/pci/controller/dwc/pci-meson.c +++ b/drivers/pci/controller/dwc/pci-meson.c @@ -261,22 +261,6 @@ static int meson_size_to_payload(struct meson_pcie *mp= , int size) return fls(size) - 8; } =20 -static void meson_set_max_payload(struct meson_pcie *mp, int size) -{ - struct dw_pcie *pci =3D &mp->pci; - u32 val; - u16 offset =3D dw_pcie_find_capability(pci, PCI_CAP_ID_EXP); - int max_payload_size =3D meson_size_to_payload(mp, size); - - val =3D dw_pcie_readl_dbi(pci, offset + PCI_EXP_DEVCTL); - val &=3D ~PCI_EXP_DEVCTL_PAYLOAD; - dw_pcie_writel_dbi(pci, offset + PCI_EXP_DEVCTL, val); - - val =3D dw_pcie_readl_dbi(pci, offset + PCI_EXP_DEVCTL); - val |=3D PCIE_CAP_MAX_PAYLOAD_SIZE(max_payload_size); - dw_pcie_writel_dbi(pci, offset + PCI_EXP_DEVCTL, val); -} - static void meson_set_max_rd_req_size(struct meson_pcie *mp, int size) { struct dw_pcie *pci =3D &mp->pci; @@ -381,7 +365,6 @@ static int meson_pcie_host_init(struct dw_pcie_rp *pp) =20 pp->bridge->ops =3D &meson_pci_ops; =20 - meson_set_max_payload(mp, MAX_PAYLOAD_SIZE); meson_set_max_rd_req_size(mp, MAX_READ_REQ_SIZE); =20 return 0; --=20 2.34.1