kernel/drivers/net/ethernet/sfc/ethtool_common.h, branch linux-6.18.y

eth: sfc: migrate to new RXFH callbacks

2025-06-21T14:53:39Z

Migrate to new callbacks added by commit 9bb00786fc61 ("net: ethtool: add dedicated callbacks for getting and setting rxfh fields"). This driver's RXFH config is read only / fixed so the conversion is purely factoring out the handling into a helper. One thing of note that this is one of the two drivers which pays attention to rss_context. Reviewed-by: Edward Cree Link: https://patch.msgid.link/20250618203823.1336156-4-kuba@kernel.org Signed-off-by: Jakub Kicinski

sfc: use new rxfh_context API

2024-06-29T01:53:21Z

The core is now responsible for allocating IDs and a memory region for us to store our state (struct efx_rss_context_priv), so we no longer need efx_alloc_rss_context_entry() and friends. Since the contexts are now maintained by the core, use the core's lock (net_dev->ethtool->rss_lock), rather than our own mutex (efx->rss_lock), to serialise access against changes; and remove the now-unused efx->rss_lock from struct efx_nic. Signed-off-by: Edward Cree Reviewed-by: Przemek Kitszel Link: https://patch.msgid.link/150274740ea8cc137fef5502541ce573d32fb319.1719502240.git.ecree.xilinx@gmail.com Signed-off-by: Jakub Kicinski

net: ethtool: get rid of get/set_rxfh_context functions

2023-12-14T06:07:16Z

Add the RSS context parameters to struct ethtool_rxfh_param and use the get/set_rxfh to handle the RSS contexts as well. This is part 2/2 of the fix suggested in [1]: - Add a rss_context member to the argument struct and a capability like cap_link_lanes_supported to indicate whether driver supports rss contexts, then you can remove *et_rxfh_context functions, and instead call *et_rxfh() with a non-zero rss_context. Link: https://lore.kernel.org/netdev/20231121152906.2dd5f487@kernel.org/ [1] CC: Jesse Brandeburg CC: Tony Nguyen CC: Marcin Wojtas CC: Russell King CC: Sunil Goutham CC: Geetha sowjanya CC: Subbaraya Sundeep CC: hariprasad CC: Saeed Mahameed CC: Leon Romanovsky CC: Edward Cree CC: Martin Habets Suggested-by: Jakub Kicinski Signed-off-by: Ahmed Zaki Link: https://lore.kernel.org/r/20231213003321.605376-3-ahmed.zaki@intel.com Signed-off-by: Jakub Kicinski

net: ethtool: pass a pointer to parameters to get/set_rxfh ethtool ops

2023-12-14T06:07:16Z

The get/set_rxfh ethtool ops currently takes the rxfh (RSS) parameters as direct function arguments. This will force us to change the API (and all drivers' functions) every time some new parameters are added. This is part 1/2 of the fix, as suggested in [1]: - First simplify the code by always providing a pointer to all params (indir, key and func); the fact that some of them may be NULL seems like a weird historic thing or a premature optimization. It will simplify the drivers if all pointers are always present. - Then make the functions take a dev pointer, and a pointer to a single struct wrapping all arguments. The set_* should also take an extack. Link: https://lore.kernel.org/netdev/20231121152906.2dd5f487@kernel.org/ [1] Suggested-by: Jakub Kicinski Suggested-by: Jacob Keller Signed-off-by: Ahmed Zaki Link: https://lore.kernel.org/r/20231213003321.605376-2-ahmed.zaki@intel.com Signed-off-by: Jakub Kicinski

sfc: remove 'log-tc-errors' ethtool private flag

2022-10-19T20:00:05Z

It no longer does anything now that we're using formatted extacks instead. So we can remove the driver's whole get/set priv_flags implementation. Signed-off-by: Edward Cree Signed-off-by: Jakub Kicinski

sfc: optional logging of TC offload errors

2022-09-28T08:43:22Z

TC offload support will involve complex limitations on what matches and actions a rule can do, in some cases potentially depending on rules already offloaded. So add an ethtool private flag "log-tc-errors" which controls reporting the reasons for un-offloadable TC rules at NETIF_INFO. Signed-off-by: Edward Cree Signed-off-by: David S. Miller

sfc: skeleton EF100 PF driver

2020-07-27T19:26:55Z

No TX or RX path, no MCDI, not even an ifup/down handler. Besides stubs, the bulk of the patch deals with reading the Xilinx extended PCIe capability, which tells us where to find our BAR. Though in the same module, EF100 has its own struct pci_driver, which is named sfc_ef100. A small number of additional nic_type methods are added; those in the TX (tx_enqueue) and RX (rx_packet) paths are called through indirect call wrappers to minimise the performance impact. Signed-off-by: Edward Cree Signed-off-by: David S. Miller

sfc: remove efx_ethtool_nway_reset()

2020-07-27T19:26:55Z

An MDIO-based n-way restart does not make sense for any of the NICs supported by this driver, nor for the coming EF100. Unlike on Falcon (which was already split off into a separate driver), the PHY on all of Siena, EF10 and EF100 is managed by MC firmware. While Siena can talk to the PHY over MDIO, doing so for anything other than debugging purposes (mdio_mii_ioctl) is likely to confuse the firmware. (According to the SFC firmware team, this support was originally added to the Siena driver early in the development of that product, before it was decided to have firmware manage the PHY.) Signed-off-by: Edward Cree Signed-off-by: David S. Miller

sfc: get drvinfo driver name from outside the common code

2020-07-02T21:47:40Z

Since ethtool_common.o will be built into both sfc and sfc_ef100 drivers, it can't use KBUILD_MODNAME directly. Instead, make it reference a string provided by the individual driver code. Signed-off-by: Edward Cree Signed-off-by: David S. Miller

sfc: commonise other ethtool bits

2020-06-30T00:37:48Z

A few more ethtool handlers which EF100 will share. Signed-off-by: Edward Cree Signed-off-by: David S. Miller