|WARNING| net/bnxt: fix channel disable bitmap handling

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: WARNING
https://dpdk.org/patch/169566

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-09-15

# DPDK Patch Review

## Patch Information
- **Subject**: net/bnxt: fix channel disable bitmap handling
- **Component**: drivers/net/bnxt
- **Type**: Bug fix

---

## Review Findings

### Errors

**1. Shift operation using literal `1` instead of `1U` for bitmask**

The patch uses `(1 << i)` for building bitmasks, where the literal `1` is a signed `int`.
While `i` is bounded by `BNXT_MPC_CHNL_MAX` and likely won't exceed 31,
using `1U` or `1UL` is the proper pattern for bitmask operations to avoid undefined behavior
and make the intent explicit.

**Location**: Lines 64 and 67

```c
/* Current (patch introduces this) */
if (!(mpc_chnl_flg & (1 << i)))
    continue;
mpc_chnl_msk |= (1 << i);

/* Should be */
if (!(mpc_chnl_flg & (1U << i)))
    continue;
mpc_chnl_msk |= (1U << i);
```

This applies to both the new line 64 and the existing line 67.
Note: The original code at line 64 had the same issue; the patch preserves it in the new location.

---

### Warnings

None identified.

---

### Info

**1. Correctness of the fix**

The patch correctly addresses the logic bug where `mpc->mpc_chnls_en` was cleared before being used
to determine which channels to disable. The fix preserves the original bitmap value
in `mpc_chnl_flg` before clearing the field, then uses the saved value in the loop.
This is the correct approach.

**2. Variable naming**

The new variable `mpc_chnl_flg` follows the existing naming convention in the function
(`mpc_chnl_msk`), maintaining consistency.

---

## Summary

The patch fixes a genuine logic bug where the channel enable bitmap was zeroed
before being used to build the disable mask, causing no channels to be selected for disabling.
The fix is correct.

The only issue is the use of signed `int` literal `1` instead of `1U` for bit shifts.
This is a pre-existing issue in the function that the patch doesn't introduce
(it already exists at line 67), but the patch does add another instance at the new line 64.
Consider fixing both occurrences while making this change.