All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Przemyslaw Korba <przemyslaw.korba@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com
Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2] ice: dpll: Fix compilation warning
Date: Wed, 25 Feb 2026 09:59:41 +0000	[thread overview]
Message-ID: <aZ7IDXaOOnwcnuuq@horms.kernel.org> (raw)
In-Reply-To: <20260223143214.241797-1-przemyslaw.korba@intel.com>

On Mon, Feb 23, 2026 at 03:31:55PM +0100, Przemyslaw Korba wrote:
> ice_dpll.c: In function ‘ice_dpll_init’:
> ice_dpll.c:3588:59: error: ‘%u’ directive output may be truncated
> writing between 1 and 10 bytes into a region of size 4
> [-Werror=format-truncation=] snprintf(pin_name, sizeof(pin_name),
> "rclk%u", i);
> 
> Fixes: ad1df4f2d591 ("ice: dpll: Support E825-C SyncE and dynamic pin discovery")
> Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com>

Hi Przemyslaw,

I agree that it is good to address this problem.
But is it a bug?

It seems to me that of the 8 bytes of pin_name, three are available for %u.
So values up to 999 can be safely formatted.  And I suspect that
pf->dplls.rclk.num_parents is always significantly smaller than that.

If so, I'd suggest this is iwl-next material. And should not have
a Fixes tag. But you could cite the commit that introduced the problem
something like this (the part starting with 'commit' is the syntax for
citing commits):

Introduced by commit ad1df4f2d591 ("ice: dpll: Support E825-C SyncE and
dynamic pin discovery")

...

WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Przemyslaw Korba <przemyslaw.korba@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com
Subject: Re: [PATCH iwl-net v2] ice: dpll: Fix compilation warning
Date: Wed, 25 Feb 2026 09:59:41 +0000	[thread overview]
Message-ID: <aZ7IDXaOOnwcnuuq@horms.kernel.org> (raw)
In-Reply-To: <20260223143214.241797-1-przemyslaw.korba@intel.com>

On Mon, Feb 23, 2026 at 03:31:55PM +0100, Przemyslaw Korba wrote:
> ice_dpll.c: In function ‘ice_dpll_init’:
> ice_dpll.c:3588:59: error: ‘%u’ directive output may be truncated
> writing between 1 and 10 bytes into a region of size 4
> [-Werror=format-truncation=] snprintf(pin_name, sizeof(pin_name),
> "rclk%u", i);
> 
> Fixes: ad1df4f2d591 ("ice: dpll: Support E825-C SyncE and dynamic pin discovery")
> Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com>

Hi Przemyslaw,

I agree that it is good to address this problem.
But is it a bug?

It seems to me that of the 8 bytes of pin_name, three are available for %u.
So values up to 999 can be safely formatted.  And I suspect that
pf->dplls.rclk.num_parents is always significantly smaller than that.

If so, I'd suggest this is iwl-next material. And should not have
a Fixes tag. But you could cite the commit that introduced the problem
something like this (the part starting with 'commit' is the syntax for
citing commits):

Introduced by commit ad1df4f2d591 ("ice: dpll: Support E825-C SyncE and
dynamic pin discovery")

...

  parent reply	other threads:[~2026-02-25  9:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23 14:31 [Intel-wired-lan] [PATCH iwl-net v2] ice: dpll: Fix compilation warning Przemyslaw Korba
2026-02-23 14:31 ` Przemyslaw Korba
2026-02-24  8:57 ` [Intel-wired-lan] " Przemek Kitszel
2026-03-02 12:01   ` Korba, Przemyslaw
2026-03-02 12:01     ` Korba, Przemyslaw
2026-02-25  9:59 ` Simon Horman [this message]
2026-02-25  9:59   ` Simon Horman
2026-03-02 12:01   ` [Intel-wired-lan] " Korba, Przemyslaw
2026-03-02 12:01     ` Korba, Przemyslaw
2026-03-02 14:04     ` [Intel-wired-lan] " Simon Horman
2026-03-02 14:04       ` Simon Horman

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=aZ7IDXaOOnwcnuuq@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=anthony.l.nguyen@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=netdev@vger.kernel.org \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=przemyslaw.korba@intel.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.