Re: [PATCH net-next v7 00/15][pull request] Introduce iXD driver

On 8/3/2026 8:16 PM, Tony Nguyen wrote:
> Larysa Zaremba says:
> 
> This patch series adds the iXD driver, which supports the Intel(R)
> Control Plane PCI Function on Intel E2100 and later IPUs and FNICs.
> It facilitates a centralized control over multiple IDPF PFs/VFs/SFs
> exposed by the same card. The reason for the separation is to be able
> to offload the control plane to the host different from where the data
> plane is running.
> 
> This is the first phase in the release of this driver where we implement the
> initialization of the core PCI driver. Subsequent phases will implement
> advanced features like usage of idpf ethernet aux device, link management,
> NVM update via devlink, switchdev port representors, data and exception path,
> flow rule programming, etc.

There's one new report from Sashiko that's a possible issue and, since 
we have to do a new version, a bunch of nice to-dos so we'll be doing a 
new version.

Thanks,
Tony

pw-bot: changes-requested

> The first phase entails the following aspects:
> 
> 1. Additional libie functionalities:
> Patches 1-5 introduce additional common library API for drivers to
> communicate with the control plane through mailbox communication.
> A control queue is a hardware interface which is used by the driver
> to interact with other subsystems (like firmware). The library APIs
> allow the driver to setup and configure the control queues to send and
> receive virtchnl messages. The library has an internal bookkeeping
> (XN API) mechanism to keep track of the send messages. It supports both
> synchronous as well as asynchronous way of handling the messages. The
> library also handles the timeout internally for synchronous messages
> using events. This reduces the driver's overhead in handling the timeout
> error cases.
> 
> The current patch series supports only APIs that are needed for device
> initialization. These include APIs in the libie_pci module:
> * Allocating/freeing the DMA memory and mapping the MMIO regions for
>    BAR0, read/write APIs for drivers to access the MMIO memory
> 
> and libie_cp module:
> * Control queue initialization and configuration
> * Transport initialization for bookkeeping
> * Blocking and asynchronous mailbox transactions
> 
> Once the mailbox is initialized, the drivers can send and receive virtchnl
> messages to/from the control plane.
> 
> The modules above are not supposed to be linked with the main libie library,
> but do share the folder with it.
> 
> 2. idpf:
> Patches 6-11 refactor the idpf driver to use the libie APIs for control
> queue configuration, virtchnl transaction, device initialization
> and reset and adjust related code accordingly.
> 
> 3. ixd:
> Patches 12-15 add the ixd driver and implement multiple pieces of the
> initialization flow as follows:
> * Add the ability to load
> * A reset is issued to ensure a clean device state, followed by
>    initialization of the mailbox
> * Device capabilities:
>    As part of initialization, the driver has to determine what the device is
>    capable of (ex. max queues, vports, etc). This information is obtained from
>    the firmware and stored by the driver.
> * Enable initial support for the devlink interface