All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Cc: <bhelgaas@google.com>, <lpieralisi@kernel.org>,
	<kwilczynski@kernel.org>, <mani@kernel.org>, <robh@kernel.org>,
	<krzk+dt@kernel.org>, <conor+dt@kernel.org>,
	<thierry.reding@gmail.com>, <jonathanh@nvidia.com>,
	<kishon@kernel.org>, <arnd@arndb.de>,
	<gregkh@linuxfoundation.org>, <Frank.Li@nxp.com>,
	<den@valinux.co.jp>, <hongxing.zhu@nxp.com>,
	<jingoohan1@gmail.com>, <vidyas@nvidia.com>, <cassel@kernel.org>,
	<18255117159@163.com>, <linux-pci@vger.kernel.org>,
	<linux-tegra@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	kernel test robot <lkp@intel.com>
Subject: Re: [PATCH 1/1] PCI: tegra194: fix min() signedness when capping ASPM L1 entrance latency
Date: Wed, 8 Apr 2026 12:58:27 +0100	[thread overview]
Message-ID: <20260408125827.7063fd83@pumpkin> (raw)
In-Reply-To: <20260407145749.130753-1-mmaddireddy@nvidia.com>

On Tue, 7 Apr 2026 20:27:49 +0530
Manikanta Maddireddy <mmaddireddy@nvidia.com> wrote:

> The DT property "aspm-l1-entry-delay-ns" is converted to microseconds,
> then encoded for the L1 entrance latency register field as ilog2(us) + 1,
> clamped to the hardware maximum of 7.
> 
> ilog2() returns int type, while the upper bound is 7U (unsigned int).
> The min() macro is implemented with __careful_cmp(), which rejects mixed
> signed and unsigned operands at compile time via BUILD_BUG_ON_MSG in
> minmax.h; that check trips on this pair, notably when building with W=1.
> 
> This combination fails to build (e.g. parisc allyesconfig, GCC 15, as
> reported by the 0-day bot).
> 
> Use min_t(u32, ilog2(us) + 1U, 7U) so both sides of the comparison are
> unsigned and consistent with aspm_l1_enter_lat.

Adding 1U (rather than 1) is enough to make everything signed.
Alternatively change the 7U to 7 and it will all be fine regardless of
whether ilog2() returns a signed or unsigned result.

Remember min_t(u32, x, y) is min((u32)x, (u32)y) and you wouldn't put in
casts like that for any other arithmetic operation.

Note that for the compile to fail there has to be a code path where
ilog2(us) isn't known to generate a non-negative value.
ilog2(us) (probably) ends up as 'fls(us) - 1'. If that is implemented using a
compiler builtin (because there is a single instruction) then gcc knows that
the input can't be zero (from the max()), so knows that fls() can't return 0
(which it does for 0), so knows it is never negative and the checks in min()
pass.

parisc may be one of the architectures that ends up with a real function
for fls() so the compiler doesn't know the result of ilog2() is
non-negative.

Just delete the U.

	David

> 
> Fixes: 4a44cd65c9dd ("PCI: tegra194: Use aspm-l1-entry-delay-ns DT property for L1 entrance latency")
> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202604051407.AODe3ddZ-lkp@intel.com/
> ---
>  drivers/pci/controller/dwc/pcie-tegra194.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> index 393f75ce3df3..93d3452ac117 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -1147,7 +1147,7 @@ static int tegra_pcie_dw_parse_dt(struct tegra_pcie_dw *pcie)
>  	if (!ret) {
>  		u32 us = max(val / 1000, 1U);
>  
> -		pcie->aspm_l1_enter_lat = min(ilog2(us) + 1, 7U);
> +		pcie->aspm_l1_enter_lat = min_t(u32, ilog2(us) + 1U, 7U);
>  	}
>  
>  	ret = of_property_read_u32(np, "num-lanes", &pcie->num_lanes);


  parent reply	other threads:[~2026-04-08 11:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-07 14:57 [PATCH 1/1] PCI: tegra194: fix min() signedness when capping ASPM L1 entrance latency Manikanta Maddireddy
2026-04-08  5:57 ` Manikanta Maddireddy
2026-04-09 16:55   ` Manivannan Sadhasivam
2026-04-08 11:58 ` David Laight [this message]
2026-04-09  7:05   ` Manikanta Maddireddy
2026-04-09 16:53     ` Manivannan Sadhasivam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260408125827.7063fd83@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=18255117159@163.com \
    --cc=Frank.Li@nxp.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=den@valinux.co.jp \
    --cc=gregkh@linuxfoundation.org \
    --cc=hongxing.zhu@nxp.com \
    --cc=jingoohan1@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=kishon@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=mmaddireddy@nvidia.com \
    --cc=robh@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=vidyas@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.