linux-kernel - Re: [PATCH v4 1/1] PCI: of: Relax max-link-speed check to support PCIe Gen5/Gen6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <jwyze44q3dte4ac3ajythb7mxy7sp2hcidugp2kowxubcp6knm@fcixtanjn2ss>
Date: Thu, 18 Dec 2025 18:14:16 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Hans Zhang <18255117159@....com>
Cc: bhelgaas@...gle.com, helgaas@...nel.org, ilpo.jarvinen@...ux.intel.com, 
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/1] PCI: of: Relax max-link-speed check to support
 PCIe Gen5/Gen6

On Thu, Dec 18, 2025 at 07:56:14PM +0800, Hans Zhang wrote:
> 
> 
> On 2025/12/18 14:31, Manivannan Sadhasivam wrote:
> > On Wed, Nov 05, 2025 at 09:47:01PM +0800, Hans Zhang wrote:
> > > The existing code restricted max-link-speed to values 1~4 (Gen1~Gen4),
> > > but current SOCs using Synopsys/Cadence IP may require Gen5/Gen6 support.
> > > While DT binding validation already checks this property, the code-level
> > > validation in of_pci_get_max_link_speed still lags behind, needing an
> > > update to accommodate newer PCIe generations.
> > > 
> > > Hardcoded literals in such validation logic create maintainability
> > > challenges, as they are difficult to track and update when adding
> > > support for future PCIe link speeds.  To address this, a helper function
> > > pcie_max_supported_link_speed() is added in drivers/pci/pci.h, which
> > > calculates the maximum supported link speed generation using existing
> > > PCIe capability macros (PCI_EXP_LNKCAP_SLS_*). This ensures alignment
> > > with the kernel's generic PCIe link speed definitions and avoids
> > > standalone hardcoded values.
> > > 
> > > The previous hardcoded "4" in the validation check is replaced with a
> > > call to this helper function, eliminating the need to modify this specific
> > > code path when extending support for future PCIe generations.
> > 
> > How can you not modify this function when PCIe 7.0 gets added? It still requires
> > an update.
> > 
> > I'd prefer to just drop the check altogether as the callers already have checks
> > on their own.
> 
> Hi Mani,
> 
> 
> Thank you very much for your reply. Do you mean the following modification?
> 
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 3579265f1198..9d3980e425b4 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -890,7 +890,7 @@ int of_pci_get_max_link_speed(struct device_node *node)
>  	u32 max_link_speed;
> 
>  	if (of_property_read_u32(node, "max-link-speed", &max_link_speed) ||
> -	    max_link_speed == 0 || max_link_speed > 4)
> +	    max_link_speed == 0)
>  		return -EINVAL;
> 
>  	return max_link_speed;
> 

Yes! But you could remove the 0 check also.

- Mani

-- 
மணிவண்ணன் சதாசிவம்