On Wed, 16 Apr 2025 21:37:09 +0400 (+04) Ivan Malov <ivan.ma...@arknetworks.am> wrote:
> On Wed, 16 Apr 2025, Stephen Hemminger wrote: > > > On Wed, 16 Apr 2025 19:38:58 +0400 (+04) > > Ivan Malov <ivan.ma...@arknetworks.am> wrote: > > > >> On Wed, 16 Apr 2025, Stephen Hemminger wrote: > >> > >>> On Wed, 16 Apr 2025 17:59:30 +0400 > >>> Ivan Malov <ivan.ma...@arknetworks.am> wrote: > >>> > >>>> New X4522 (dual port SFP56) and X4542 (dual port QSFP56) adaptors are > >>>> Medford4 (X4) chips that are based on EF10 architecture. An X4 NIC > >>>> supports multiple network engine types. This series provides support > >>>> only for the Medford2-alike, 'full-feature' (FF) network engine. This > >>>> shall not be confused with the concept of 'datapath FW variants': the > >>>> FF network engine supports both 'full-feature' and 'ultra-low-latency' > >>>> datapath FW variants, with corresponding Medford2-alike feature sets. > >>>> > >>>> The first part of the series provides general support for the adaptors, > >>>> whilst the second one adds support for the new management controller > >>>> interface for configuration of network port features (netport MCDI). > >>>> > >>>> For now, only support for physical functions (PFs) is concerned. There > >>>> is a small number of TODO and FIXME markings in the code. Those are > >>>> normal at this development stage and will be removed by future patches > >>>> when VF support has fleshed out. > >>>> > >>>> > >>>> Andy Moreton (3): > >>>> common/sfc_efx/base: update X4 BAR layout and PCI IDs > >>>> net/sfc: add Medford4 with only full feature datapath engine > >>>> common/sfc_efx/base: add port mode for 8 port hardware > >>>> > >>>> Denis Pryazhennikov (15): > >>>> common/sfc_efx/base: add Medford4 PCI IDs to common code > >>>> common/sfc_efx/base: add efsys option for Medford4 > >>>> common/sfc_efx/base: add Medford4 support to NIC module > >>>> common/sfc_efx/base: add Medford4 support to EV module > >>>> common/sfc_efx/base: add Medford4 support to FILTER module > >>>> common/sfc_efx/base: add Medford4 support to INTR module > >>>> common/sfc_efx/base: add Medford4 support to MAC module > >>>> common/sfc_efx/base: add Medford4 support to PHY module > >>>> common/sfc_efx/base: add Medford4 support to TUNNEL module > >>>> common/sfc_efx/base: add Medford4 support to MCDI module > >>>> common/sfc_efx/base: add Medford4 support to Rx module > >>>> common/sfc_efx/base: add Medford4 support to Tx module > >>>> drivers: enable support for AMD Solarflare X4 adapter family > >>>> common/sfc_efx/base: add new X4 port mode > >>>> common/sfc_efx/base: extend list of supported X4 port modes > >>>> > >>>> Ivan Malov (28): > >>>> common/sfc_efx/base: update MCDI headers > >>>> common/sfc_efx/base: provide a stub for basic netport attach > >>>> common/sfc_efx/base: provide defaults on netport attach path > >>>> common/sfc_efx/base: obtain assigned netport handle from NIC > >>>> common/sfc_efx/base: allow for const in MCDI struct accessor > >>>> common/sfc_efx/base: get netport fixed capabilities on probe > >>>> common/sfc_efx/base: decode netport link state on probe path > >>>> common/sfc_efx/base: fill in loopback modes on netport probe > >>>> common/sfc_efx/base: introduce Medford4 stub for PHY methods > >>>> common/sfc_efx/base: refactor EF10 link mode decoding helper > >>>> common/sfc_efx/base: provide PHY link get method on Medford4 > >>>> common/sfc_efx/base: implement PHY link control for Medford4 > >>>> common/sfc_efx/base: introduce Medford4 stub for MAC methods > >>>> common/sfc_efx/base: add MAC reconfigure method for Medford4 > >>>> common/sfc_efx/base: fill in software LUT for MAC statistics > >>>> common/sfc_efx/base: fill in MAC statistics mask on Medford4 > >>>> common/sfc_efx/base: support MAC statistics on Medford4 NICs > >>>> common/sfc_efx/base: implement MAC PDU controls for Medford4 > >>>> common/sfc_efx/base: correct MAC PDU calculation on Medford4 > >>>> net/sfc: make use of generic EFX MAC PDU calculation helpers > >>>> common/sfc_efx/base: ignore legacy link events on new boards > >>>> common/sfc_efx/base: add link event processing on new boards > >>>> net/sfc: query link status on link change events on new NICs > >>>> common/sfc_efx/base: subscribe to netport link change events > >>>> net/sfc: offer support for 200G link ability on new adaptors > >>>> common/sfc_efx/base: support controls for netport lane count > >>>> net/sfc: add support for control of physical port lane count > >>>> doc: advertise support for AMD Solarflare X45xx adapters > >>>> > >>>> .mailmap | 3 +- > >>>> doc/guides/nics/sfc_efx.rst | 9 +- > >>>> doc/guides/rel_notes/release_25_07.rst | 4 + > >>>> drivers/common/sfc_efx/base/ef10_ev.c | 39 + > >>>> drivers/common/sfc_efx/base/ef10_impl.h | 19 + > >>>> drivers/common/sfc_efx/base/ef10_nic.c | 98 +- > >>>> drivers/common/sfc_efx/base/ef10_phy.c | 43 +- > >>>> drivers/common/sfc_efx/base/ef10_tlv_layout.h | 9 +- > >>>> drivers/common/sfc_efx/base/efx.h | 98 +- > >>>> drivers/common/sfc_efx/base/efx_check.h | 24 +- > >>>> drivers/common/sfc_efx/base/efx_ev.c | 6 + > >>>> drivers/common/sfc_efx/base/efx_filter.c | 6 + > >>>> drivers/common/sfc_efx/base/efx_impl.h | 115 +- > >>>> drivers/common/sfc_efx/base/efx_intr.c | 6 + > >>>> drivers/common/sfc_efx/base/efx_mac.c | 56 +- > >>>> drivers/common/sfc_efx/base/efx_mcdi.c | 18 +- > >>>> drivers/common/sfc_efx/base/efx_mcdi.h | 2 +- > >>>> drivers/common/sfc_efx/base/efx_nic.c | 60 + > >>>> drivers/common/sfc_efx/base/efx_np.c | 1625 +++++ > >>>> drivers/common/sfc_efx/base/efx_phy.c | 88 +- > >>>> drivers/common/sfc_efx/base/efx_port.c | 1 + > >>>> drivers/common/sfc_efx/base/efx_regs_mcdi.h | 5868 ++++++++++++++++- > >>>> drivers/common/sfc_efx/base/efx_rx.c | 6 + > >>>> drivers/common/sfc_efx/base/efx_tunnel.c | 18 +- > >>>> drivers/common/sfc_efx/base/efx_tx.c | 33 + > >>>> drivers/common/sfc_efx/base/medford4_impl.h | 110 + > >>>> drivers/common/sfc_efx/base/medford4_mac.c | 299 + > >>>> drivers/common/sfc_efx/base/medford4_phy.c | 156 + > >>>> drivers/common/sfc_efx/base/meson.build | 3 + > >>>> drivers/common/sfc_efx/efsys.h | 2 + > >>>> drivers/common/sfc_efx/sfc_base_symbols.c | 2 + > >>>> drivers/net/sfc/sfc.c | 5 +- > >>>> drivers/net/sfc/sfc.h | 4 + > >>>> drivers/net/sfc/sfc_dp_tx.h | 3 + > >>>> drivers/net/sfc/sfc_ef10_tx.c | 13 +- > >>>> drivers/net/sfc/sfc_ethdev.c | 186 +- > >>>> drivers/net/sfc/sfc_ev.c | 51 +- > >>>> drivers/net/sfc/sfc_port.c | 27 +- > >>>> drivers/net/sfc/sfc_repr.c | 7 +- > >>>> drivers/net/sfc/sfc_repr.h | 1 + > >>>> drivers/net/sfc/sfc_tx.c | 2 + > >>>> 41 files changed, 9000 insertions(+), 125 deletions(-) > >>>> create mode 100644 drivers/common/sfc_efx/base/efx_np.c > >>>> create mode 100644 drivers/common/sfc_efx/base/medford4_impl.h > >>>> create mode 100644 drivers/common/sfc_efx/base/medford4_mac.c > >>>> create mode 100644 drivers/common/sfc_efx/base/medford4_phy.c > >>>> > >>> > >>> Overall looks good but: > >>> - need to fix build on FreeBSD, you are using an errno not available > >>> there. > >>> - can you address some of the checkpatch warnings in the base code. > >>> > >> > >> I can fix the errno, yes. Thanks for catching this. > >> > >> As for the checkpatch warnings in the base code -- unfortunately, that > >> part does > >> not follow DPDK style in general and has always triggered such warnings in > >> DPDK. > >> Should I try to fix some anyway? Which, for instance? > > > > Mostly it is the use of BSD style parens on returns that clutters the > > warnings. > > I.e > > return (0); > > I see. Unfortunately, this, as well as space character in 'sizeof ()', follows > the base driver's own style and it has been so for a long time. May be it is > acceptable to retain it. But I do care to comply with DPDK conventions in the > SFC driver itself. So shall I fix ENODATA->ENODEV and send v2? As long as isn't too weird, base code can follow a slightly different set of rules. Please send v2 and do a test build on FreeBSD (in a vm is fine).
