> -----Original Message----- > From: Lobakin, Aleksander <[email protected]> > Sent: Wednesday, April 16, 2025 8:49 AM > To: Zaremba, Larysa <[email protected]> > Cc: [email protected]; Nguyen, Anthony L > <[email protected]>; David S. Miller <[email protected]>; > Dumazet, Eric <[email protected]>; Jakub Kicinski <[email protected]>; > Paolo Abeni <[email protected]>; Simon Horman <[email protected]>; > Jonathan Corbet <[email protected]>; Kitszel, Przemyslaw > <[email protected]>; Jiri Pirko <[email protected]>; Mustafa Ismail > <[email protected]>; Nikolova, Tatyana E > <[email protected]>; Andrew Lunn <[email protected]>; > Michael Ellerman <[email protected]>; Fijalkowski, Maciej > <[email protected]>; Lee Trager <[email protected]>; Madhavan > Srinivasan <[email protected]>; Samudrala, Sridhar > <[email protected]>; Keller, Jacob E <[email protected]>; > Michal Swiatkowski <[email protected]>; Polchlopek, Mateusz > <[email protected]>; Wenjun Wu <[email protected]>; Zaki, > Ahmed <[email protected]>; [email protected]; linux- > [email protected]; [email protected]; Karlsson, Magnus > <[email protected]>; Tantilov, Emil S <[email protected]>; > Chittim, Madhu <[email protected]>; Hay, Joshua A > <[email protected]>; Olech, Milena <[email protected]>; Linga, > Pavan Kumar <[email protected]>; Singhai, Anjali > <[email protected]> > Subject: Re: [PATCH iwl-next 00/14] Introduce iXD driver > > From: Larysa Zaremba <[email protected]> > Date: Tue, 8 Apr 2025 14:47:46 +0200 > > > 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. > > BTW please move everything you're adding to libeth to libie instead. > This PCI/VC/CP functionality is unlikely to be used by other vendors. > Since libie_cp.ko or how you may want to call it won't link with base > libie.ko, it won't have any pre-idpf HW-specific symbols, so that idpf > could link with it. > libeth stuff is purely vendor-agnostic and I'd really like to keep it so. > > Thanks, > Olek
I agree with this too. Thanks, Jake
