[PATCH v3 0/9] ENETC driver related changes series

[Stephen Hemminger]

On Tue, 23 Jun 2026 17:21:59 +0000
Gagandeep Singh <G.Singh at nxp.com> wrote:

> It seems that AI reviewed the V2 series instead of the V3 series. I have manually verified that the first two issues are fixed in the V3 series. For the last issue, I will submit a separate patch as a new feature, introducing KEEP_CRC for the enetc4 driver. Additionally, AI has acknowledged that there will be no functional issue as of now, since crc_len will be only 0.


It was my bad, was looking earlier in that chat.
Looks clean will apply

For V3:

v3 re-review. I diffed every patch against v2; the only substantive code change is in 7/9, and the rest of the delta is documentation.

Both v2 blockers are resolved:

The kvlist leak in enetc4_vf_dev_init() (was Error) is fixed — rte_kvargs_free(kvlist) now precedes both the invalid-timeout and invalid-delay return -1 paths.

The missing devargs documentation (was Warning) is now in doc/guides/nics/enetc4.rst: a new "Driver Arguments (devargs)" section split into VF-specific (enetc4_vsi_disable, enetc4_vsi_timeout, enetc4_vsi_delay) and PF/Common (enetc4_txq_prior, nc) subsections, each with a usage example. Section underlines are the correct length (19/19 and 17/17), so it builds clean under -W; defaults and applicability match the code.

No new issues introduced — patches 1–6 and 8 are byte-identical to v2 apart from the doc hunks, and patch 9's only delta is the nc doc plus line-number offsets shifted by patch 7's two added lines.

For the record, the one item carried over from v2 is unchanged and remains non-blocking: in the RX reassembly paths, first_seg->pkt_len -= crc_len at frame-last doesn't adjust the final segment's data_len, so pkt_len != sum(data_len) if crc_len != 0. This stays latent because enetc4 doesn't advertise RTE_ETH_RX_OFFLOAD_KEEP_CRC (crc_len is always 0). Worth a guard only if KEEP_CRC is ever added; not a reason to hold the series.

No open errors, no open warnings.