Re: [PATCH iwl-next] ixgbe: fix ITR value overflow in adaptive interrupt throttling

[Simon Horman <horms@kernel.org>]

On Fri, Mar 27, 2026 at 08:30:45AM +0100, Aleksandr Loktionov wrote:
> ixgbe_update_itr() packs a mode flag (IXGBE_ITR_ADAPTIVE_LATENCY, bit 7)
> and a usecs delay (bits [6:0]) into an unsigned int, then stores it in
> ring_container->itr which is u8.  Values above 0xFF wrap, corrupting both
> the delay and the mode-flag on the next readback.
> 
> Separate the mode bits from the usecs sub-field; clamp only the latter to
> [0, IXGBE_ITR_ADAPTIVE_LATENCY - 1] via min_t(unsigned int, ...) so
> overflow cannot bleed into bit 7.  Add a WARN_ONCE() when the raw usecs
> value exceeds U8_MAX so out-of-range ITR computations are visible in
> dmesg during development and testing.
> 
> Fixes: b4ded8327fea ("ixgbe: Update adaptive ITR algorithm")
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Somehow - perhaps because there is no m/n notation present in the [] in the
subject - Patchwork has treated each patch in this series as it's own
patch-set.

And in the case of this patch, it didn't apply - I assume
because in order to do so an earlier patch in the series
needs to be present.

So CI didn't run on this patch :(