> -----Original Message----- > From: Lobakin, Aleksander <aleksander.lobakin@xxxxxxxxx> > Sent: Wednesday, April 16, 2025 8:49 AM > To: Zaremba, Larysa <larysa.zaremba@xxxxxxxxx> > Cc: intel-wired-lan@xxxxxxxxxxxxxxxx; Nguyen, Anthony L > <anthony.l.nguyen@xxxxxxxxx>; David S. Miller <davem@xxxxxxxxxxxxx>; > Dumazet, Eric <edumazet@xxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; > Paolo Abeni <pabeni@xxxxxxxxxx>; Simon Horman <horms@xxxxxxxxxx>; > Jonathan Corbet <corbet@xxxxxxx>; Kitszel, Przemyslaw > <przemyslaw.kitszel@xxxxxxxxx>; Jiri Pirko <jiri@xxxxxxxxxxx>; Mustafa Ismail > <mustafa.ismail@xxxxxxxxx>; Nikolova, Tatyana E > <tatyana.e.nikolova@xxxxxxxxx>; Andrew Lunn <andrew+netdev@xxxxxxx>; > Michael Ellerman <mpe@xxxxxxxxxxxxxx>; Fijalkowski, Maciej > <maciej.fijalkowski@xxxxxxxxx>; Lee Trager <lee@xxxxxxxxx>; Madhavan > Srinivasan <maddy@xxxxxxxxxxxxx>; Samudrala, Sridhar > <sridhar.samudrala@xxxxxxxxx>; Keller, Jacob E <jacob.e.keller@xxxxxxxxx>; > Michal Swiatkowski <michal.swiatkowski@xxxxxxxxxxxxxxx>; Polchlopek, Mateusz > <mateusz.polchlopek@xxxxxxxxx>; Wenjun Wu <wenjun1.wu@xxxxxxxxx>; Zaki, > Ahmed <ahmed.zaki@xxxxxxxxx>; netdev@xxxxxxxxxxxxxxx; linux- > doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Karlsson, Magnus > <magnus.karlsson@xxxxxxxxx>; Tantilov, Emil S <emil.s.tantilov@xxxxxxxxx>; > Chittim, Madhu <madhu.chittim@xxxxxxxxx>; Hay, Joshua A > <joshua.a.hay@xxxxxxxxx>; Olech, Milena <milena.olech@xxxxxxxxx>; Linga, > Pavan Kumar <pavan.kumar.linga@xxxxxxxxx>; Singhai, Anjali > <anjali.singhai@xxxxxxxxx> > Subject: Re: [PATCH iwl-next 00/14] Introduce iXD driver > > From: Larysa Zaremba <larysa.zaremba@xxxxxxxxx> > 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