NXP/Freescale DPAA2 Management Complex Bus
The control-plane bus that lets Linux discover and manage objects inside NXP's Data Path Acceleration Architecture v2 (DPAA2), the packet-processing engine built into Freescale/NXP Layerscape network SoCs such as the LS2088A and LX2160A. Networking appliances and embedded gear use it to wire up the on-chip Ethernet and accelerator blocks on these ARM parts, which NXP still ships new.
recommendation
It should stay in the kernel because NXP still actively sells and markets DPAA2-capable Layerscape SoCs like the LX2160A, and the code is receiving regular fixes and stable backports as recently as April 2026. Deployments are niche (embedded networking and edge appliances rather than consumer hardware), but the maintenance signal is healthy and the bus is the entry point Linux uses to talk to DPAA2 networking hardware at all.
repository signals
sources
- lore.kernel.org
Recent upstream maintenance exists: April 2026 fix for a refcount leak in fsl-mc core code.
- lore.kernel.org
The driver is still receiving fixes and stable backports in 2026, indicating active supported use rather than abandonment.
- docs.kernel.org
Kernel documentation describes the Management Complex (MC) as the control plane for DPAA2 hardware resources and objects used by Linux drivers.
- nxp.com
NXP's LX2160A product page was active in 2026 search results and advertises DPAA2, showing relevant hardware still marketed new.
codex reasoning notes (technical)
`exec_command` listed multiple .c files and `fsl-mc-bus.c` identifies this as the Freescale/NXP Management Complex bus driver, so it is a real driver directory. `lore_file_timeline` on `drivers/bus/fsl-mc/fsl-mc-bus.c` showed dense activity through 2025-2026, with cited April 2026 fixes from lore URLs above; that supports `keep`, not deprecate. `web.search_query` found current kernel DPAA2 docs and NXP's active LX2160A page, supporting ongoing new-hardware relevance; deployments are niche embedded/networking rather than mass-market, hence `medium`. `lore_regex`/`lore_substr_subject` removal probes timed out and `lei` was blocked by sandbox, so the lack of a removal discussion is an inference from available evidence, not exhaustive proof.