|WARNING| net/bnxt: prevent overflow in alarm timeout calculation

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

# DPDK Patch Review

## Patch Summary
This patch addresses integer overflow in alarm timeout calculations in the Broadcom NetXtreme PMD (bnxt driver). The fix widens `uint32_t` wait values to `uint64_t` before multiplying by `US_PER_MS`.

---

## Review Findings

### Errors

**None identified.**

### Warnings

**None identified.**

### Info

**1. Suggested improvement: cast `US_PER_MS` instead of the variable**

The patch casts `info->driver_polling_freq`, `wait_msec`, and `polling_freq` to `uint64_t` on the right side of the multiply. However, `US_PER_MS` is a macro typically defined as `1000` (an `int` constant). A clearer pattern is to cast the constant:

```c
/* Current patch approach - correct but less idiomatic */
rte_eal_alarm_set(US_PER_MS * (uint64_t)wait_msec, ...);

/* Suggested alternative - cast the constant */
rte_eal_alarm_set((uint64_t)US_PER_MS * wait_msec, ...);
```

Both forms are correct and prevent overflow. Casting the constant is slightly more idiomatic in DPDK code (similar to `UINT64_C(1)` patterns) and makes it clear that the entire expression is evaluated at 64-bit width. However, the current patch is functionally correct and the difference is purely stylistic.

---

## Conclusion

This patch correctly fixes the integer overflow issue identified in the guidelines (32x32 multiply assigned to 64-bit result). The fix is appropriate for backporting to stable branches (`Cc: stable at dpdk.org` is present). No functional or correctness issues found.