|WARNING| crypto/cnxk: fix AE table get on unprobed device

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

# DPDK Patch Review

## Summary
This patch fixes NULL pointer dereference bugs in two PMD API functions by correcting device ID validation. The changes are correct and improve robustness.

---

## Errors

None.

---

## Warnings

**Missing explicit NULL comparison in new validation check**

LOCATION: `drivers/crypto/cnxk/cnxk_cryptodev_ops.c:1134`

The code uses implicit boolean evaluation on the validation function:
```c
if (!rte_cryptodev_is_valid_dev(dev_id)) {
```

Per DPDK coding style (AGENTS.md "Comparisons and Boolean Logic"), explicit comparison against 0 is required for non-bool return values. The function `rte_cryptodev_is_valid_dev()` returns `int`, not `bool`.

Suggested fix:
```c
if (rte_cryptodev_is_valid_dev(dev_id) == 0) {
    plt_err("Invalid dev_id %u", dev_id);
    return NULL;
}
```

Same issue at line 1161.

Note: This mechanical rewrite is typically handled by coccinelle scripts in `devtools/cocci/`, but should be flagged for completeness.

---

## Info

**Good defensive programming**

The addition of NULL pointer check for `nb_max_entries` parameter (lines 1156-1159) prevents a potential NULL dereference if the caller passes NULL. This is good practice for a public PMD API function that will write through this pointer.

**Correct fix for the core bug**

The patch correctly identifies that `rte_cryptodev_pmd_get_dev()` returns a pointer into a static array and cannot be used to validate device existence. Using `rte_cryptodev_is_valid_dev()` before dereferencing `dev->data` is the right approach.

---

## Positive Observations

1. **Fixes real correctness bugs**: The original code would dereference `dev->data` on an unprobed device, causing NULL pointer access
2. **Consistent fix pattern**: Both affected functions receive the same treatment
3. **Proper error messages**: Error logging provides actionable information
4. **Fixes tags present**: Correctly identifies the commits that introduced the bugs