[PATCH v18 00/24] NXP DPAA driver enhancements and fixes

[Stephen Hemminger]

On Wed, 30 Sep 2026 11:54:13 +0530
Hemant Agrawal <hemant.agrawal at nxp.com> wrote:

> This series collects a set of fixes and enhancements for the NXP DPAA
> bus, mempool, dma, crypto and net drivers targeting 26.11.
> 
> It includes memory-leak and resource-cleanup fixes on the device
> remove/close paths, more robust frame queue and congestion-group
> shutdown, secondary-process safety guards, BPID and cgrid lifecycle
> handling, and several new features: offline (O/H) port device support,
> enhanced virtual storage profile (VSP) port support, fmcless Rx queue
> configuration via devargs, Rx/Tx taildrop threshold devargs, non
> fmX-macY shared Ethernet naming, and DMA scatter-gather and
> errata-workaround devargs. Documentation and release notes are updated
> accordingly.
> 
> v18:
> * Dropped the "net/dpaa: fix device remove" patch. It papered over the
>   symptom in rte_dpaa_remove() instead of fixing the cause, and was
>   replaced by the two fixes now at the head of the series.
> * net/dpaa: fix the double dpaa_eth_dev_close() call and the eth_dev
>   dereference before the NULL check in rte_dpaa_remove().
> * net/dpaa: unwind rte_dpaa_probe() through cleanup labels so the Tx SG
>   mempool failure path closes the device and releases the port instead of
>   leaking the port, the queue arrays and the QMan FQID/CGRID ranges.

[PATCH v5-S1 0/5] dpaa2 bus/dma/mempool fixes

Series

Info

  cdefd2e980bd made the same scan/probe move for bus/dpaa, and that
  bus has the problem this series fixes for fslmc.
  rte_dpaa_bus_scan() calls rte_mbuf_set_platform_mempool_ops()
  (memzone reserve) and dpaax_iova_table_populate() (rte_zmalloc)
  before EAL runs rte_eal_memzone_init() and
  rte_eal_malloc_heap_init(). Both return values are ignored.
  bus/dpaa needs a matching fix.

  Patch 1 reverses part of cdefd2e980bd (the move to generic probe).
  Cc David Marchand.


Patch 2/5: bus/fslmc: reduce probe-time logging and skip ignored
devices

Warning

  The commit message says "clean up a redundant variable assignment
  while there", but the fslmc_vfio.c hunk only changes the log
  call. Drop the stale sentence.

Warning

  +		if (rte_bus_device_is_ignored(&rte_fslmc_bus, dev->device.name))
  +			continue;

  This skip leaves ep_dev_type, ep_object_id and ep_name unset for
  devices that stay on the bus. fslmc_vfio_process_group() only
  removes devices with devargs->policy == RTE_DEV_BLOCKED. In
  allowlist mode, unlisted devices stay on the list, still go
  through fslmc_process_iodevices(), and can be attached later with
  rte_dev_probe() because fslmc sets .probe_device. Such a dpni
  keeps ep_dev_type == 0 (DPAA2_ETH, from the calloc() in
  scan_one_fslmc_device()) and ep_object_id == 0. The loopback setup
  in dpaa2_recycle.c then treats dpni.0 as self-connected, and a
  DPMAC-connected port gets -ENOTSUP.

  The commit message does not say what fails without the check. If
  the problem is dprc_get_connection() failing for an ignored dpni
  and aborting the whole DPRC, make that failure non-fatal: set
  DPAA2_UNKNOWN and continue instead of skipping the query. If this
  fixes a regression, add a Fixes tag.

  The log level change and the ignore check are unrelated. Split
  them into separate patches.

Info

  Pre-existing, not introduced by this patch:

  	sprintf(dev->ep_name, "%s.%d", endpoint2.type, endpoint2.id);

  This runs for every device, but endpoint2 is only initialized in
  the DPAA2_ETH branch. A non-ETH device ahead of the first dpni
  formats uninitialized stack, and type[16] need not be NUL
  terminated.

Info

  Pre-existing: net/dpaa2 never assigns priv->ep_dev_type,
  priv->ep_object_id or priv->ep_name. The test
  "if (priv->ep_dev_type != DPAA2_MAC)" in dpaa2_ethdev.c reads a
  field nothing writes, and rte_pmd_dpaa2_ep_name() returns a buffer
  nothing fills.


Patch 3/5: dma/dpaa2: fix array-bounds warning and SG FD double-put

Error

  The SG FD change does not fix a bug. Before the patch, fle_sdd was
  stored in fle_elem[] ahead of qdma_cntx_idx_ring_eq(). On -ENOSPC,
  dpaa2_qdma_dequeue() clears pending, leaves the loop, and still
  runs:

  	rte_mempool_put_bulk(qdma_vq->fle_pool,
  		qdma_vq->fle_elem, fle_elem_nb);

  So the FLE went back to the pool exactly once. After the patch it
  also goes back exactly once, through rte_mempool_put(). There was
  no double put. rte_mempool_free() does not free objects
  individually, so the described "double-free when the pool was
  later destroyed" cannot happen. The DPAA2_QDMA_FD_LONG branch just
  above keeps the same store-before-enqueue order. Drop this half,
  or reword it as a cleanup with no Fixes or stable tag.

Warning

  The array-bounds half does not name the compiler, version or
  target, and does not quote the diagnostic. The pre-patch loop
  builds clean on x86_64 with GCC 13.3 and 14.2 at -O3 -Werror
  -Warray-bounds=2. The loop it replaces came from 07d679bceee3
  ("dma/dpaa2: refactor driver"), not 388e888dc082, so the Fixes
  tag does not cover it. Make it a separate patch with its own
  Fixes tag and the warning text in the message.

Info

  Pre-existing: when dpaa2_qdma_dq_fd() returns -ENOSPC, the FD has
  already been pulled from hardware. Its cntx_idx values never reach
  the ring, so rte_dma_completed() never reports those jobs. The
  early exit on

  	if (ret || free_space < RTE_DPAAX_QDMA_JOB_SUBMIT_MAX)
  		pending = 0;

  also abandons any later results already written to dq_storage,
  because active_dqs is then switched to dq_storage1.


Patch 4/5: dma/dpaa2: validate FLE pool IOVA mapping at vchan setup

Info

  The check confirms each chunk has an fslmc mapping. It does not
  check the property the fast path relies on. Enqueue converts every
  FLE with

  	fle_iova = (uint64_t)fle - qdma_vq->fle_iova2va_offset;

  and that offset comes from fle_pool->mz. That memzone is the
  mempool header (mp->mz in rte_mempool_create_empty()), not the
  object chunks reserved in rte_mempool_populate_default(). The
  callback already has memhdr->iova. Comparing
  (uint64_t)memhdr->addr - memhdr->iova against the offset would
  catch a pool spread over chunks with different VA/IOVA offsets
  (IOVA as PA with fragmented hugepages). The offset handling itself
  is pre-existing.

Info

  Pre-existing: later error paths still leave the stale pool that
  the commit message describes. The two rte_mempool_get_bulk()
  failures in silent mode and the ring_cntx_idx allocation failure
  return without freeing fle_pool. The fle_elem rte_malloc() result
  is never checked and is written in dpaa2_qdma_dq_fd().


Patch 5/5: mempool/dpaa2: look up ops index locally in secondary

Warning

  This fixes a bug from de6a6e897fe6 ("mempool/dpaa2: add operation
  index"), which shipped in 25.07 and is in 25.11 LTS. In a
  secondary process, dpaa2_sec compares mb_pool->ops_index against
  the sentinel and always takes the MAX_BPID path. Add:

  Fixes: de6a6e897fe6 ("mempool/dpaa2: add operation index")
  Cc: stable at dpdk.org