This series introduces NCSI (Network Controller Sideband Interface)
passthrough support for USB CDC Ethernet devices and fixes a
use-after-free race condition in the NCSI core unregistration path.

In DPU (Data Processing Unit) platforms such as the NVIDIA BlueField
series, the Baseboard Management Controller (BMC) communicates with the
host or DPU via a dedicated USB CDC Ethernet connection for out-of-band
management traffic.

Unlike traditional platform Ethernet devices where NCSI is initialized
statically at probe time, USB devices require dynamic lifecycle
management within ndo_open() and ndo_stop():

1. NCSI control packets share the USB data path, requiring the link
   carrier to remain enabled while the interface is up.
2. In USB drivers, usbnet_disconnect() invokes unregister_netdev()
   before unbind(). Performing NCSI registration in ndo_open() and
   cleanup in ndo_stop() ensures NCSI packet handlers are removed before
   netdevice teardown occurs.
3. Dynamic unregistration of NCSI devices revealed a race in the NCSI
   core: ncsi_unregister_dev() freed the ncsi_dev_priv structure while
   asynchronous request timers and workqueue items were still active.

Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
---
Adrian Ambrozewicz (2):
      net: usb: cdc_ether: add NCSI passthrough support
      net/ncsi: fix use-after-free in ncsi_unregister_dev()

 drivers/net/usb/Kconfig     |  20 +++++
 drivers/net/usb/cdc_ether.c | 190 +++++++++++++++++++++++++++++++++++++++++++-
 net/ncsi/ncsi-manage.c      |  19 +++++
 3 files changed, 228 insertions(+), 1 deletion(-)
---
base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f
change-id: 20260907-ncsi-over-usb-3e786f4686c8

Best regards,
--  
Potin Lai <potin.lai.pt@gmail.com>

On Mon, Sep 07, 2026 at 08:15:54PM +0800, Potin Lai wrote:
> This series introduces NCSI (Network Controller Sideband Interface)
> passthrough support for USB CDC Ethernet devices and fixes a
> use-after-free race condition in the NCSI core unregistration path.
> 
> In DPU (Data Processing Unit) platforms such as the NVIDIA BlueField
> series, the Baseboard Management Controller (BMC) communicates with the
> host or DPU via a dedicated USB CDC Ethernet connection for out-of-band
> management traffic.

I'm confused with the architecture here. What normally happens is the
BMC has a standard Ethernet interface which outputs RGMII. That goes
into what is in effect a little 3 port switch in the host
interface. That switch allows packets to flow to the host, to the BMC,
or out the PHY to the medium.

Because the PHY is in effect being shared by two interfaces,
management of that PHY becomes "Interesting". You don't want either of
the interfaces setting the PHY down because it would cut the other off
from the medium.

What is the architecture then USB is used?

     Andrew

On Tue, Sep 8, 2026 at 2:23 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Mon, Sep 07, 2026 at 08:15:54PM +0800, Potin Lai wrote:
> > This series introduces NCSI (Network Controller Sideband Interface)
> > passthrough support for USB CDC Ethernet devices and fixes a
> > use-after-free race condition in the NCSI core unregistration path.
> >
> > In DPU (Data Processing Unit) platforms such as the NVIDIA BlueField
> > series, the Baseboard Management Controller (BMC) communicates with the
> > host or DPU via a dedicated USB CDC Ethernet connection for out-of-band
> > management traffic.
>
> I'm confused with the architecture here. What normally happens is the
> BMC has a standard Ethernet interface which outputs RGMII. That goes
> into what is in effect a little 3 port switch in the host
> interface. That switch allows packets to flow to the host, to the BMC,
> or out the PHY to the medium.
>
> Because the PHY is in effect being shared by two interfaces,
> management of that PHY becomes "Interesting". You don't want either of
> the interfaces setting the PHY down because it would cut the other off
> from the medium.
>
> What is the architecture then USB is used?
>
>      Andrew

Hi Andrew,

Thanks for the review. To clarify the architecture, it looks like this:

[ BMC ] <--(USB)--> [ SMA Controller ] <--(Internal)--> [ Shared NIC (CX9) ]

1. The USB Interface: Between the BMC and the shared NIC, there is an
   SMA controller. This controller emulates a standard USB CDC Ethernet
   device facing the BMC.

2. Passthrough (Bypass): The SMA controller acts as a transparent bridge.
   It simply passes through both standard network packets and NCSI
   control packets between the BMC's USB interface and the actual
   shared NIC.

3. PHY Management: Because of this architecture, the actual 3-port switch
   logic and the physical PHY management are handled entirely by the
   NIC/SMA hardware firmware on the DPU side.

From the BMC's perspective, it only sees a point-to-point USB CDC Ethernet
device. The BMC driver does not have direct access to manage the shared
PHY's link state.

Best regards,
Potin

> Hi Andrew,
> 
> Thanks for the review. To clarify the architecture, it looks like this:
> 
> [ BMC ] <--(USB)--> [ SMA Controller ] <--(Internal)--> [ Shared NIC (CX9) ]
> 
> 1. The USB Interface: Between the BMC and the shared NIC, there is an
>    SMA controller. This controller emulates a standard USB CDC Ethernet
>    device facing the BMC.
> 
> 2. Passthrough (Bypass): The SMA controller acts as a transparent bridge.
>    It simply passes through both standard network packets and NCSI
>    control packets between the BMC's USB interface and the actual
>    shared NIC.
> 
> 3. PHY Management: Because of this architecture, the actual 3-port switch
>    logic and the physical PHY management are handled entirely by the
>    NIC/SMA hardware firmware on the DPU side.

This is the first time i've seen this sort of setup. You should
explain this in the commit message, because it is probably new to
others as well.

> >From the BMC's perspective, it only sees a point-to-point USB CDC Ethernet
> device. The BMC driver does not have direct access to manage the shared
> PHY's link state.

So why is the SMA controller emulator actually reporting the true link
state? Since it is an emulator, why not just say the link is always
up? And ignore any requests from the BMC to change its state? You then
don't need any quirks in the CDC driver. It seems silly to emulator
something and not actually use the fact it is an emulation to hide
away differences to a real device.

      Andrew