- 20 Jan, 2023 14 commits
-
-
Jiri Pirko authored
Similar to other devlink objects, rely on devlink instance lock and remove object specific reporters_lock. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Similar to other devlink objects, protect the reporters list by devlink instance lock. Alongside add unlocked versions of health reporter create/destroy functions and use them in drivers on call paths where the instance lock is held. Signed-off-by:
-
Jiri Pirko authored
The MLX5E_LOCKED_FLOW flag is not checked anywhere now so remove it entirely. Signed-off-by:
-
Jiri Pirko authored
The fact that devlink instance lock is held over mlx5 auxiliary devices probe and remove routines brought a need to conditionally take devlink instance lock there. The code is checking a MLX5E_LOCKED_FLOW flag in mlx5 priv struct. This is racy and may lead to access devlink objects without holding instance lock or deadlock. To avoid this, the only lock-wise sane solution is to make the devlink entities created by the auxiliary device independent on the original pci devlink instance. Create devlink instance for the auxiliary device and put the uplink port instance there alongside with the port health reporters. Signed-off-by:
-
Jiri Pirko authored
As long as the linecard life time is protected by devlink instance lock, the reference counting is no longer needed. Remove it. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
-
Jiri Pirko authored
Similar to other devlink objects, convert the linecards list to be protected by devlink instance lock. Alongside with that rename the create/destroy() functions to devl_* to indicate the devlink instance lock needs to be held while calling them. Signed-off-by:
-
Siddharth Vadapalli authored
In the am65_cpsw_init_serdes_phy() function, the error handling for the call to the devm_of_phy_get() function misses the case where the return value of devm_of_phy_get() is ERR_PTR(-EPROBE_DEFER). Proceeding without handling this case will result in a crash when the "phy" pointer with this value is dereferenced by phy_init() in am65_cpsw_enable_phy(). Fix this by adding appropriate error handling code. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Fixes: dab2b265 ("net: ethernet: ti: am65-cpsw: Add support for SERDES configuration") Suggested-by:
Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by:
Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20230118112136.213061-1-s-vadapalli@ti.comSigned-off-by:
-
Dan Carpenter authored
We want to return negative error codes here but the copy_to/from_user() functions return the number of bytes remaining to be copied. Fixes: c59e12a1 ("net: dsa: microchip: ptp: Initial hardware time stamping support") Signed-off-by:
Dan Carpenter <error27@gmail.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/Y8fJxSvbl7UNVHh/@kiliSigned-off-by:
-
Jakub Kicinski authored
Russell King says: ==================== net: sfp: cleanup i2c / dt / acpi / fwnode / includes This series cleans up the DT/fwnode/ACPI code in the SFP cage driver: 1. Use the newly introduced i2c_get_adapter_by_fwnode(), which removes the need to know about ACPI handles to find the I2C device. 2. Use device_get_match_data() to get the match data, rather than having to look up the matching DT device_id to get at the data. 3. Rename gpio_of_names, as this is not DT specific. 4. Remove acpi.h include which is no longer necessary. 5. Remove ctype.h include which, as far as I can tell, was never necessary. ==================== Link: https://lore.kernel.org/r/Y8fH+Vqx6huYQFDU@shell.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
An include of linux/ctype.h was added in commit 1323061a ("net: phy: sfp: Add HWMON support for module sensors") but nothing was used from this header file. Remove this unnecessary include. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Russell King (Oracle) authored
Nothing in the sfp code now references anything from the ACPI header, everything is done via fwnode APIs, so get rid of this header. Signed-off-by:
-
Russell King (Oracle) authored
There's nothing DT specific about the gpio_of_names array, let's drop the _of infix. Signed-off-by:
-
Russell King (Oracle) authored
Rather than using of_match_node() to get the matching of_device_id to then retrieve the match data, use device_get_match_data() instead to avoid firmware specific functions, and free the driver from having firmware specific code. Signed-off-by:
-
Russell King (Oracle) authored
Use the newly introduced i2c_get_adapter_by_fwnode() API, so that we can retrieve the I2C adapter in a firmware independent manner once we have the fwnode handle for the adapter. Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
- 19 Jan, 2023 25 commits
-
-
Paolo Abeni authored
Michael Walle says: ==================== net: phy: Remove probe_capabilities With all the drivers which used .probe_capabilities converted to the new c45 MDIO access methods, we can now decide based upon these whether a bus driver supports c45 and we can get rid of the not widely used probe_capabilites. Unfortunately, due to a now broader support of c45 scans, this will trigger a bug on some boards with a (c22-only) Micrel PHY. These PHYs don't ignore c45 accesses correctly, thinking they are addressed themselves and distrupt the MDIO access. To avoid this, a blacklist for c45 scans is introduced. ==================== Link: https://lore.kernel.org/r/20230116-net-next-remove-probe-capabilities-v2-0-15513b05e1f4@walle.ccSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Andrew Lunn authored
Deciding if to probe of PHYs using C45 is now determine by if the bus provides the C45 read method. This makes probe_capabilities redundant so remove it. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by:
Andrew Jeffery <andrew@aj.id.au> Signed-off-by:
-
Andrew Lunn authored
Some PHYs provide invalid IDs in C22 space. If C45 is supported on the bus an attempt can be made to get the IDs from the C45 space. Decide on this based on the presence of the C45 read method in the bus structure. This will allow the unreliable probe_capabilities to be removed. Signed-off-by:
-
Andrew Lunn authored
Now that all MDIO bus drivers which set probe_capabilities to MDIOBUS_C22_C45 have been converted to use the name API for C45 transactions, perform the scanning of the bus based on which methods the bus provides. Signed-off-by:
-
Andrew Lunn authored
After scanning the bus for C22 devices, check if any Micrel PHYs have been found. They are known to do bad things if there are C45 transactions on the bus. Prevent the scanning of the bus using C45 if such a PHY has been detected. Signed-off-by:
-
Andrew Lunn authored
Some C22 PHYs do bad things when there are C45 transactions on the bus. In order to handle this, the bus needs to be scanned first for C22 at all addresses, and then C45 scanned for all addresses. The Marvell pxa168 driver scans a specific address on the bus to find its PHY. This is a C22 only device, so update it to use the c22 helper. Signed-off-by:
-
Andrew Lunn authored
No functional change, just place it earlier in preparation for some refactoring. While at it, correct the comment format and one typo. Signed-off-by:
-
Paolo Abeni authored
Pavithra Sathyanarayanan says: ==================== generic implementation of phy interface and fixed_phy support for the LAN743x device This patch series includes the following changes: - Remove the unwanted interface settings in the LAN743x driver as it is preset in EEPROM configurations. - Handle generic implementation for the phy interfaces for different devices LAN7430/31 and pci11x1x. - Add new feature for fixed_phy support at 1Gbps full duplex for the LAN7431 device if a phy not found over MDIO. Includes support for communication between a MAC in a LAN7431 device and custom phys without an MDIO interface. ==================== Link: https://lore.kernel.org/r/20230117141614.4411-1-Pavithra.Sathyanarayanan@microchip.comSigned-off-by:
-
Pavithra Sathyanarayanan authored
Add fixed_phy support at 1Gbps full duplex for the lan7431 device if a phy not found over MDIO. Tested with a MAC to MAC connection from LAN7431 to a KSZ9893 switch. This avoids the Driver open error in LAN743x. TX delay and internal CLK125 generation is already enabled in EEPROM. Signed-off-by:
Pavithra Sathyanarayanan <Pavithra.Sathyanarayanan@microchip.com> Signed-off-by:
-
Pavithra Sathyanarayanan authored
Add logic to read the Phy interface from MAC_CR register for LAN743x driver. Checks for the LAN7430/31 or pci11x1x devices and the adapter interface is updated accordingly. For LAN7431, adapter interface is set based on Bit 19 of MAC_CR register as MII or RGMII which removes the forced RGMII/GMII configurations in lan743x_phy_open(). Signed-off-by:
-
Pavithra Sathyanarayanan authored
Remove the MII/RGMII Selection settings in driver as it is preset by the EEPROM and has the required configurations before the driver loads for LAN743x. Signed-off-by:
-
Hangbin Liu authored
There are some issues with the bpf/nat6to4.c building. 1. It use TEST_CUSTOM_PROGS, which will add the nat6to4.o to kselftest-list file and run by common run_tests. 2. When building the test via `make -C tools/testing/selftests/ TARGETS="net"`, the nat6to4.o will be build in selftests/net/bpf/ folder. But in test udpgro_frglist.sh it refers to ../bpf/nat6to4.o. The correct path should be ./bpf/nat6to4.o. 3. If building the test via `make -C tools/testing/selftests/ TARGETS="net" install`. The nat6to4.o will be installed to kselftest_install/net/ folder. Then the udpgro_frglist.sh should refer to ./nat6to4.o. To fix the confusing test path, let's just move the nat6to4.c to net folder and build it as TEST_GEN_FILES. Fixes: edae34a3 ("selftests net: add UDP GRO fraglist + bpf self-tests") Tested-by:
Björn Töpel <bjorn@kernel.org> Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Link: https://lore.kernel.org/r/20230118020927.3971864-1-liuhangbin@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Vladimir Oltean says: ==================== ENETC BD ring cleanup The highlights of this patch set are: - Installing a BPF program and changing PTP RX timestamping settings are currently implemented through a port reconfiguration procedure which triggers an AN restart on the PHY, and these procedures are not generally guaranteed to leave the port in a sane state. Patches 9/12 and 11/12 address that. - Attempting to put the port down (or trying to reconfigure it) has the driver oppose some resistance if it's bombarded with RX traffic (it won't go down). Patch 12/12 addresses that. The other 9 patches are just cleanup in the BD ring setup/teardown code, which gradually led to bringing the driver in a position where resolving those 2 issues was possible. ==================== Link: https://lore.kernel.org/r/20230117230234.2950873-1-vladimir.oltean@nxp.comSigned-off-by:
-
Vladimir Oltean authored
napi_synchronize() from enetc_stop() waits until the softirq has finished execution and no longer wants to be rescheduled. However under high traffic load, this will never happen, and the interface can never be closed. The problem is the fact that the NAPI poll routine is written to update the consumer index which makes the device want to put more buffers in the RX ring, which restarts the madness again. Browsing around, it seems that some drivers like i40e keep a bit (__I40E_VSI_DOWN) which they use as communication between the control path and the data path. But that isn't my first choice, because complications ensue - since the enetc hardirq may trigger while we are in a theoretical ENETC_DOWN state, it may happen that enetc_msix() masks it, but enetc_poll() never unmasks it. To prevent a stall in that case, one would need to schedule all NAPI instances when ENETC_DOWN gets cleared, to process what's pending. I find it more desirable for the control path - enetc_stop() - to just quiesce the RX ring and let the softirq finish what remains there, without any explicit communication, just by making hardware not provide any more packets. This seems possible with the Enable bit of the RX BD ring (RBaMR[EN]). I can't seem to find an exact definition of what this bit does, but when the RX ring is disabled, the port seems to no longer update the producer index, and not react to software updates of the consumer index. In fact, the RBaMR[EN] bit is already toggled by the driver, but too late for what we want: enetc_close() -> enetc_stop() -> napi_synchronize() -> enetc_clear_bdrs() -> enetc_clear_rxbdr() The enetc_clear_bdrs() function contains not only logic to disable the RX and TX rings, but also logic to wait for the TX ring stop being busy. We split enetc_clear_bdrs() into enetc_disable_bdrs() and enetc_wait_bdrs(). One needs to run before napi_synchronize() and the other after (NAPI also processes TX completions, so we maximize our chances of not waiting for the ENETC_TBSR_BUSY bit - unless a packet is stuck for some reason, ofc). We also split off enetc_enable_bdrs() from enetc_setup_bdrs(), and call this from the mirror position in enetc_start() compared to enetc_stop(), i.e. right before netif_tx_start_all_queues(). Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
Offloading a BPF program to the RX path of the driver suffers from the same problems as the PTP reconfiguration - improper error checking can leave the driver in an invalid state, and the link on the PHY is lost. Reuse the enetc_reconfigure() procedure, but here, we need to run some code in the middle of the ring reconfiguration procedure - while the interface is still down. Introduce a callback which makes that possible. Signed-off-by:
-
Vladimir Oltean authored
Follow the convention from this driver, which is to name "struct net_device *" as "ndev", and the convention from other drivers, to name "struct netdev_bpf *" as "bpf". Signed-off-by:
-
Vladimir Oltean authored
The crude enetc_stop() -> enetc_open() mechanism suffers from 2 problems: 1. improper error checking 2. it involves phylink_stop() -> phylink_start() which loses the link Right now, the driver is prepared to offer a better alternative: a ring reconfiguration procedure which takes the RX BD size (normal or extended) as argument. It allocates new resources (failing if that fails), stops the traffic, and assigns the new resources to the rings. Signed-off-by:
-
Vladimir Oltean authored
We want to introduce a fast interface reconfiguration procedure, which involves temporarily stopping the rings. But we want enetc_start() and enetc_stop() to not restart PHY autoneg, because that can take a few seconds until it completes again. So we need part of enetc_start() and enetc_stop(), but not all of them. Move phylink_start() right next to phylink_of_phy_connect(), and phylink_stop() right next to phylink_disconnect_phy(), both still in ndo_open() and ndo_stop(). Signed-off-by:
-
Vladimir Oltean authored
We have a few instances in the enetc driver where the ring resources (BD ring iomem, software BD ring, software TSO headers, basically everything except RX buffers) need to be reallocated. For example, when RX timestamping is enabled, the RX BD format changes to an extended one (twice as large). Currently, this is done using a simplistic enetc_close() -> enetc_open() procedure. But this is quite crude, since it also invokes phylink_stop() -> phylink_start(), the link is lost, and a few seconds need to pass for autoneg to complete again. In fact it's bad also due to the improper (yolo) error checking. In case we fail to allocate new resources, we've already freed the old ones, so the interface is more or less stuck. To avoid that, we need a system where reconfiguration is possible in a way in which resources are allocated upfront. This means that there will be a higher memory usage temporarily, but the assignment of resources to rings can be done when both the old and new resources are still available. Introduce a struct enetc_bdr_resource which holds the resources for a ring, be it RX or TX. This structure duplicates a lot of fields from struct enetc_bdr (and access to the same fields in the ring structure was left duplicated, to not change cache characteristics in the fast path). When enetc_alloc_tx_resources() runs, it returns an array of resource elements (one per TX ring), in addition to the existing priv->tx_res. To populate priv->tx_res with that array, one must call enetc_assign_tx_resources(), and this also frees the old resources. Signed-off-by:
-
Vladimir Oltean authored
Extended RX buffer descriptors are necessary if they carry RX timestamps, which will be true when PTP timestamping is enabled. Right now, the rx_ring->ext_en is set from the function that allocates ring resources (enetc_alloc_rx_resources() -> enetc_alloc_rxbdr()), and also used later, in enetc_setup_rxbdr(). It is also used in the enetc_rxbd() and enetc_rxbd_next() fast path helpers. We want to decouple resource allocation from BD ring setup, but both procedures depend on BD size (extended or not). Move the "extended" boolean to enetc_open() and pass it both to the RX allocation procedure as well as to the RX ring setup procedure. The latter will set rx_ring->ext_en from now on. Signed-off-by:
-
Vladimir Oltean authored
The call path in enetc_close() is: enetc_close() -> enetc_free_rxtx_rings() -> enetc_free_tx_ring() -> enetc_free_tx_frame() -> enetc_free_tx_resources() -> enetc_free_txbdr() -> enetc_free_tx_frame() The enetc_free_tx_frame() function is written such that the second call exits without doing anything, but nonetheless, it is completely redundant. Delete it. This makes the TX teardown path more similar to the RX one, where rx_swbd freeing is done in enetc_free_rx_ring(), not in enetc_free_rxbdr(). Signed-off-by: -
Vladimir Oltean authored
The call path in enetc_close() is: enetc_close() -> enetc_free_rxtx_rings() -> enetc_free_rx_ring() -> tests whether rx_ring->rx_swbd is NULL -> enetc_free_tx_ring() -> tests whether tx_ring->tx_swbd is NULL -> enetc_free_rx_resources() -> enetc_free_rxbdr() -> sets rxr->rx_swbd to NULL -> enetc_free_tx_resources() -> enetc_free_txbdr() -> setx txr->tx_swbd to NULL From the above, it is clear that due to the function ordering, the checks for NULL are redundant, since the software buffer descriptor arrays have not yet been set to NULL. Drop these checks. Signed-off-by: -
Vladimir Oltean authored
This is a refactoring change which introduces the opposite function of enetc_dma_alloc_bdr(). Signed-off-by:
-
Vladimir Oltean authored
There is only one place which needs to set up indices in the RX ring. Be consistent with what was done in the TX path and do this in enetc_setup_rxbdr(). Signed-off-by:
-
Vladimir Oltean authored
enetc_alloc_txbdr() deals with allocating resources necessary for a TX ring to work (the array of software BDs and the array of TSO headers). The next_to_clean and next_to_use pointers are overwritten with proper values which are read from hardware here: enetc_open -> enetc_alloc_tx_resources -> enetc_alloc_txbdr -> set to zero -> enetc_setup_bdrs -> enetc_setup_txbdr -> read from hardware So their initialization with zeroes is pointless and confusing. Delete it. Consequently, since enetc_setup_txbdr() has no opposite cleanup function, also delete the resetting of these indices from enetc_free_tx_ring(). Signed-off-by:
-
- 18 Jan, 2023 1 commit
-
-
Magnus Karlsson authored
Document in the XDP_REDIRECT manual section that drivers must call xdp_do_flush() before napi_complete_done(). The two reasons behind this can be found following the links below. Signed-off-by:
Magnus Karlsson <magnus.karlsson@intel.com> Link: https://lore.kernel.org/r/20221220185903.1105011-1-sbohrer@cloudflare.com Link: https://lore.kernel.org/all/20210624160609.292325-1-toke@redhat.com/Acked-by:
Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
