Re: [PATCH v2 2/3] cxl/pci: Program the Port GPF timeouts before caching the DVSEC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] cxl: build fragility due to FIELD_PREP/FIELD_GET non-constant mask usage
--

commit 502048ecbaa85e66fc08a6f9dd92c92082d18d7f
Author: Guixin Liu <kanie@linux.alibaba.com>

cxl/pci: Program the Port GPF timeouts before caching the DVSEC

This commit delays caching the Port GPF DVSEC offset until both configuration
phases are successfully programmed. This ensures that any endpoint attach
attempts will retry the setup if a configuration write fails.

> diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
> --- a/drivers/cxl/core/pci.c
> +++ b/drivers/cxl/core/pci.c
> @@ -849,7 +849,7 @@ static int update_gpf_port_dvsec(struct pci_dev *pdev, int dvsec, int phase)
>  
>  	rc = pci_read_config_word(pdev, dvsec + offset, &ctrl);
>  	if (rc)
> -		return rc;
> +		return pcibios_err_to_errno(rc);
>  
>  	if (FIELD_GET(base, ctrl) == GPF_TIMEOUT_BASE_MAX &&
>  	    FIELD_GET(scale, ctrl) == GPF_TIMEOUT_SCALE_MAX)
> @@ -859,11 +859,17 @@ static int update_gpf_port_dvsec(struct pci_dev *pdev, int dvsec, int phase)
>  	ctrl |= FIELD_PREP(scale, GPF_TIMEOUT_SCALE_MAX);
>  
>  	rc = pci_write_config_word(pdev, dvsec + offset, ctrl);
> -	if (!rc)
> -		pci_dbg(pdev, "Port GPF phase %d timeout: %d0 secs\n",
> -			phase, GPF_TIMEOUT_BASE_MAX);
> +	if (rc) {
> +		rc = pcibios_err_to_errno(rc);
> +		pci_warn(pdev, "Port GPF phase %d timeout write failed: %d\n",
> +			 phase, rc);
> +		return rc;
> +	}

[Severity: Low]
Does adding this error handling and logging run the risk of breaking the
build on some compiler configurations?

Both FIELD_GET() and FIELD_PREP() internally use a BUILD_BUG_ON_MSG() macro
that strictly requires their mask arguments to be compile-time constants.
In update_gpf_port_dvsec(), base and scale are dynamically assigned
variables rather than constants.

This code currently builds only because the compiler heuristically inlines
the function or performs interprocedural constant propagation.

Because this patch increases the size of update_gpf_port_dvsec(), is there a
risk that compiler heuristics might decide against inlining it (such as when
compiling with -Os), which would expose the BUILD_BUG_ON_MSG() failure?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008034619.28059-1-kanie@linux.alibaba.com?part=2