From nobody Tue Feb 10 02:01:22 2026 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 0E9F32853EE; Tue, 6 May 2025 17:35:49 +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=1746552953; cv=none; b=MV4XMnbsvf2ihxbmCEXJ1hCodod8T7667x3A8e/F3Oijn7V2lbZMyEHeFNluIkAG7u89YRJe70GVjWr0zgHw2ZxPNZdnIzGF92h7ON14ra0dQ8tZBiLBJJLu6mjLXpRwYKRAaI1MfHagKnS0zVXGWKWXi8M+9coANP1834HdCcY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746552953; c=relaxed/simple; bh=zxzc/PmTJsrnSeo8yDdERrxe3HwZ9JgY/zcE56X7O9g=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=fZYv4v1GwDbDtNItCm6VMX1h+5HOZHfCApoyLKGDvXwHvEqCSzGvwZ8EMI0F5wXYKF9bZCC7RTxDY67IOzAHbAG0FRnV0UzbPFqU1pnO50F3Hs6Wgk2Bta2WtlORRnawHnKwG8rvSPsK+svAP05P7cTgTqXYGq53s62i7I++J8U= 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=fvyufsTQ; 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="fvyufsTQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-Id:MIME-Version; bh=pjYFa SOXw6nvqbq4IDi+uXJUjRekOycaZIZRolfobi0=; b=fvyufsTQd2ABuLR+pk0LT 13Dqm5uQ1Z9Oqfn4YkO7iSVzazDCH8W5MI3iIva/Kl9WrzCg9sTdWN+fFGaxy1UF hyGy2iebiM3D8kl6urgiyBYcem4IgVVmH50/yYnWsRBN9Q8CCECU/+L8wgMfNOzp nBBQspJQWe9LxXQRIiA4as= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g0-3 (Coremail) with SMTP id _____wAX_U4ySBpoVmZeEw--.15363S3; Wed, 07 May 2025 01:34:44 +0800 (CST) From: Hans Zhang <18255117159@163.com> To: lpieralisi@kernel.org, kw@linux.com, bhelgaas@google.com, heiko@sntech.de, manivannan.sadhasivam@linaro.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, 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>, Niklas Cassel Subject: [PATCH v3 1/3] PCI: Configure root port MPS during host probing Date: Wed, 7 May 2025 01:34:37 +0800 Message-Id: <20250506173439.292460-2-18255117159@163.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250506173439.292460-1-18255117159@163.com> References: <20250506173439.292460-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: _____wAX_U4ySBpoVmZeEw--.15363S3 X-Coremail-Antispam: 1Uf129KBjvJXoWxWw4rCrW8KFWrtFy7GF43GFg_yoWrAF1rpa y3XFWftrZ7GF1fWanxJa109w15trsav343trZxGw1F9w15AFyUKryYya1rJas7GrZ7uFya vr90qry8WanYvF7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zi2NtcUUUUU= X-CM-SenderInfo: rpryjkyvrrlimvzbiqqrwthudrp/1tbiOg9Fo2gaRElteAAAs5 Content-Type: text/plain; charset="utf-8" Current PCIe initialization logic may leave root ports operating with non-optimal Maximum Payload Size (MPS) settings. While downstream device configuration is handled during bus enumeration, root port MPS values inherited from firmware or hardware defaults might not utilize the full capabilities supported by the controller hardware. This can result is uboptimal data transfer efficiency across the PCIe hierarchy. During host controller probing phase, when PCIe bus tuning is enabled, the implementation now configures root port MPS settings to their hardware-supported maximum values. By iterating through bridge devices under the root bus and identifying PCIe root ports, each port's MPS is set to 128 << pcie_mpss to match the device's maximum supported payload size. Explicit initialization at host probing stage ensures consistent PCIe topology configuration before downstream devices perform their own MPS negotiations. This proactive approach addresses platform-specific requirements where controller drivers depend on properly initialized root port settings, while maintaining backward compatibility through PCIE_BUS_TUNE_OFF conditional checks. Hardware capabilities are fully utilized without altering existing device negotiation behaviors. Suggested-by: Niklas Cassel Signed-off-by: Hans Zhang <18255117159@163.com> --- drivers/pci/probe.c | 66 ++++++++++++++++++++++++--------------------- 1 file changed, 35 insertions(+), 31 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 364fa2a514f8..365d9a7dd37f 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -2149,6 +2149,37 @@ int pci_setup_device(struct pci_dev *dev) return 0; } =20 +static void pcie_write_mps(struct pci_dev *dev, int mps) +{ + int rc; + + if (pcie_bus_config =3D=3D PCIE_BUS_PERFORMANCE) { + mps =3D 128 << dev->pcie_mpss; + + if (pci_pcie_type(dev) !=3D PCI_EXP_TYPE_ROOT_PORT && + dev->bus->self) + + /* + * For "Performance", the assumption is made that + * downstream communication will never be larger than + * the MRRS. So, the MPS only needs to be configured + * for the upstream communication. This being the case, + * walk from the top down and set the MPS of the child + * to that of the parent bus. + * + * Configure the device MPS with the smaller of the + * device MPSS or the bridge MPS (which is assumed to be + * properly configured at this point to the largest + * allowable MPS based on its parent bus). + */ + mps =3D min(mps, pcie_get_mps(dev->bus->self)); + } + + rc =3D pcie_set_mps(dev, mps); + if (rc) + pci_err(dev, "Failed attempting to set the MPS\n"); +} + static void pci_configure_mps(struct pci_dev *dev) { struct pci_dev *bridge =3D pci_upstream_bridge(dev); @@ -2178,6 +2209,10 @@ static void pci_configure_mps(struct pci_dev *dev) return; } =20 + if (pci_pcie_type(dev) =3D=3D PCI_EXP_TYPE_ROOT_PORT && + pcie_bus_config !=3D PCIE_BUS_TUNE_OFF) + pcie_write_mps(dev, 128 << dev->pcie_mpss); + if (!bridge || !pci_is_pcie(bridge)) return; =20 @@ -2875,37 +2910,6 @@ static int pcie_find_smpss(struct pci_dev *dev, void= *data) return 0; } =20 -static void pcie_write_mps(struct pci_dev *dev, int mps) -{ - int rc; - - if (pcie_bus_config =3D=3D PCIE_BUS_PERFORMANCE) { - mps =3D 128 << dev->pcie_mpss; - - if (pci_pcie_type(dev) !=3D PCI_EXP_TYPE_ROOT_PORT && - dev->bus->self) - - /* - * For "Performance", the assumption is made that - * downstream communication will never be larger than - * the MRRS. So, the MPS only needs to be configured - * for the upstream communication. This being the case, - * walk from the top down and set the MPS of the child - * to that of the parent bus. - * - * Configure the device MPS with the smaller of the - * device MPSS or the bridge MPS (which is assumed to be - * properly configured at this point to the largest - * allowable MPS based on its parent bus). - */ - mps =3D min(mps, pcie_get_mps(dev->bus->self)); - } - - rc =3D pcie_set_mps(dev, mps); - if (rc) - pci_err(dev, "Failed attempting to set the MPS\n"); -} - static void pcie_write_mrrs(struct pci_dev *dev) { int rc, mrrs; --=20 2.25.1 From nobody Tue Feb 10 02:01:22 2026 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 319D1207E03; Tue, 6 May 2025 17:35:51 +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=1746552955; cv=none; b=c+Np8V3vcboA06QfP4WsQMpqbwGiY4yYphyqd/NH6/pCVTlWOa3FGm8A3cv4Z32iXuzWA8WPdUHKS9zigtdUSmb/NAZiVAoPyCIX7AguaX/Ryk4p8cCrP28LkHqiS23A219ddgZVlrYNZBUgnGGFfShlWE5tqRyTFyyEkvcGBDw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746552955; c=relaxed/simple; bh=YbY4BzhwwS0Bs97W2qpZD/tuPkcUHS6xrK4/be/t7fU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=gJy7tIt7xkDcEQizQTOGmGw6NJIwkTR23TWup36/aW1ykTx/KqUwGlChNz4KEXI7eZu4utQvCJdVHUhG3cPzL36fEJa8aMO9UzuWTt7auUlElEFRPH6EDkbR5zal2Pudw1AEvGhqpTCuIRIKhTjiZ+MfBZsk98WfpH0B51JdOLo= 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=Ku9j4yB8; 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="Ku9j4yB8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-Id:MIME-Version; bh=E2ofU gHGCmm1xPAFMa2TsfZAr9ZO/RTFbitpv1wF7q0=; b=Ku9j4yB8bqcIRuacRvWR2 JmqYyIcdjVdeDw7VRI/f0VgCY0YZPTpP9YQozV+v2lbGUxY2nWzm2qVQnm3ho2KB qrt7Yh80LPSDE0W/9+clgmoKqToBOBc1F4xRGPla4e7usfiCGeuccj6O4tLsV4KU 1ONqvuJ38aJWQwWfzPt1Ik= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g0-3 (Coremail) with SMTP id _____wAX_U4ySBpoVmZeEw--.15363S4; Wed, 07 May 2025 01:34:45 +0800 (CST) From: Hans Zhang <18255117159@163.com> To: lpieralisi@kernel.org, kw@linux.com, bhelgaas@google.com, heiko@sntech.de, manivannan.sadhasivam@linaro.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, 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 v3 2/3] PCI: dwc: Remove redundant MPS configuration Date: Wed, 7 May 2025 01:34:38 +0800 Message-Id: <20250506173439.292460-3-18255117159@163.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250506173439.292460-1-18255117159@163.com> References: <20250506173439.292460-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: _____wAX_U4ySBpoVmZeEw--.15363S4 X-Coremail-Antispam: 1Uf129KBjvJXoW7KF4xuw4xXFWDJw43WF4xtFb_yoW8Cr1fpF y3Xrsa9F18Jr45WF4qkan5Cay3tasxCry7JF9Ig3yfuFyayFsrXa4ayFWSkFyxXrW293WS kr98K3y8C3W5trUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRn2-nUUUUU= X-CM-SenderInfo: rpryjkyvrrlimvzbiqqrwthudrp/1tbiOghFo2gaREltegABs9 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> --- 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 db9482a113e9..126f38ed453d 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.25.1 From nobody Tue Feb 10 02:01:22 2026 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.3]) (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 DC07E285407; Tue, 6 May 2025 17:35:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.3 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746552953; cv=none; b=pw/jyIgLZkGHM69BvuRqI9087QnBqBs99L/zoVaoI/QXj5SB2kUiQ7WLPw8nUo3S5ofI3YFy86iCWFQ9cNyZZZwyChTx108VrTuB1Mi/twLwYTjJFGYHAsK5AeqShaOvm+rTzttodAFUb5JfoUwGj4vXrS64UbWEtRVMAe/kqjA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746552953; c=relaxed/simple; bh=6PpeytAq0ZIKuJp8mHxX/IX4SA59S0aTD3J/khpCVBc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=sfUDeG9negQXvM5d/QtRq3LSMOsw4SVtBenKWWXa0RqpR7eve9UHG7adTLSMyfNlJ2TxrvVY/O8+eyByXOcTSMY+TB7679FnKTUh5In0VM7vKKR8W87q+0yPKifoZgKDH2Bi9T8BQB8QXmwxAvvii1czrsoNBPt4Av5iNFcEiI0= 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=fwJNIuGv; arc=none smtp.client-ip=117.135.210.3 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="fwJNIuGv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-Id:MIME-Version; bh=fhcsu unrHkitcMq06j2dmcMWJJ4ZWepHigEVMlm5Ntc=; b=fwJNIuGvotdgzmFf5WEWY JVCiZ1xHK5eZxGb3NshUF4fsNCa3MLCjYHdfJosbPj0Q+XnmEqb64o2gCmefFxAj rjbqWOncap4VArENcJX2E6CzZxQAKRhJwysOX2saxVITpsLzrCdR8TZiMk1P37k4 XRQsDGF5G6JifXIc4o6MIg= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g0-3 (Coremail) with SMTP id _____wAX_U4ySBpoVmZeEw--.15363S5; Wed, 07 May 2025 01:34:46 +0800 (CST) From: Hans Zhang <18255117159@163.com> To: lpieralisi@kernel.org, kw@linux.com, bhelgaas@google.com, heiko@sntech.de, manivannan.sadhasivam@linaro.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, 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 v3 3/3] PCI: aardvark: Remove redundant MPS configuration Date: Wed, 7 May 2025 01:34:39 +0800 Message-Id: <20250506173439.292460-4-18255117159@163.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250506173439.292460-1-18255117159@163.com> References: <20250506173439.292460-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: _____wAX_U4ySBpoVmZeEw--.15363S5 X-Coremail-Antispam: 1Uf129KBjvJXoW7Zr47trWUAFWUCF43Gr4kJFb_yoW8Xry8pF 9xXF4xtF4ftr15u3ZrA3WkKry3JasFkFy5W398W3yfZF9xtryUGFyayryrAayxJr4kGFyj y34YyrWFy3W3twUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07UeGQDUUUUU= X-CM-SenderInfo: rpryjkyvrrlimvzbiqqrwthudrp/1tbiOhVFo2gaREltogAAs5 Content-Type: text/plain; charset="utf-8" The Aardvark PCIe controller enforces a fixed 512B payload size via PCI_EXP_DEVCTL_PAYLOAD_512B, overriding hardware capabilities and PCIe core negotiations. Remove explicit MPS overrides (PCI_EXP_DEVCTL_PAYLOAD and PCI_EXP_DEVCTL_PAYLOAD_512B). MPS is now determined by the PCI core during device initialization, leveraging root port configurations and device-specific capabilities. Aligning Aardvark with the unified MPS framework ensures consistency, avoids artificial constraints, and allows the hardware to operate at its maximum supported payload size while adhering to PCIe specifications. Signed-off-by: Hans Zhang <18255117159@163.com> --- drivers/pci/controller/pci-aardvark.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller= /pci-aardvark.c index a29796cce420..d8852892994a 100644 --- a/drivers/pci/controller/pci-aardvark.c +++ b/drivers/pci/controller/pci-aardvark.c @@ -549,9 +549,7 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie) reg =3D advk_readl(pcie, PCIE_CORE_PCIEXP_CAP + PCI_EXP_DEVCTL); reg &=3D ~PCI_EXP_DEVCTL_RELAX_EN; reg &=3D ~PCI_EXP_DEVCTL_NOSNOOP_EN; - reg &=3D ~PCI_EXP_DEVCTL_PAYLOAD; reg &=3D ~PCI_EXP_DEVCTL_READRQ; - reg |=3D PCI_EXP_DEVCTL_PAYLOAD_512B; reg |=3D PCI_EXP_DEVCTL_READRQ_512B; advk_writel(pcie, reg, PCIE_CORE_PCIEXP_CAP + PCI_EXP_DEVCTL); =20 --=20 2.25.1