summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet
AgeCommit message (Collapse)AuthorFilesLines
2021-06-11net: pcs: xpcs: rename mdio_xpcs_args to dw_xpcsVladimir Oltean2-2/+2
The struct mdio_xpcs_args is reminiscent of when a similarly named struct mdio_xpcs_ops existed. Now that that is removed, we can shorten the name to dw_xpcs (dw for DesignWare). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: qualcomm: rmnet: avoid unnecessary IPv6 byte-swappingAlex Elder1-8/+9
In the previous patch IPv4 download checksum offload code was updated to avoid unnecessary byte swapping, based on properties of the Internet checksum algorithm. This patch makes comparable changes to the IPv6 download checksum offload handling. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: qualcomm: rmnet: avoid unnecessary byte-swappingAlex Elder1-4/+4
Internet checksums are used for IPv4 header checksum, as well as TCP segment and UDP datagram checksums. Such a checksum represents the negated sum of adjacent pairs of bytes, using ones' complement arithmetic. One property of the Internet checkum is byte order independence [1]. Specifically, the sum of byte-swapped pairs is equal to the result of byte swapping the sum of those same pairs when not byte-swapped. So for example if a, b, c, d, y, and z are hexadecimal digits, and PLUS represents ones' complement addition: If: ab PLUS cd = yz Then: ba PLUS dc = zy For this reason, there is no need to swap the order of bytes in the checksum value held in a message header, nor the one in the QMAPv4 trailer, in order to operate on them. In other words, we can determine whether the hardware-computed checksum matches the one in the message header without any byte swaps. (This patch leaves in place all existing type casts.) [1] https://tools.ietf.org/html/rfc1071 Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: qualcomm: rmnet: clarify a bit of codeAlex Elder1-10/+16
In rmnet_map_ipv6_dl_csum_trailer() there is an especially involved line of code that determines the ones' complement sum of the IPv6 packet header (in host byte order). Simplify that by storing the result of computing just the header checksum in a local variable, then using that in the original assignment. Use the size of the IPv6 header structure as the number of bytes to checksum, rather than computing the offset to the transport header. And use ip_fast_csum() rather than ipa_compute_csum(), knowing that the size of an IPv6 header (40 bytes) is a multiple of 4 bytes greater than 16. Add some comments to match rmnet_map_ipv4_dl_csum_trailer(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: qualcomm: rmnet: IPv4 header has zero checksumAlex Elder3-14/+29
In rmnet_map_ipv4_dl_csum_trailer(), an illegal checksum subtraction is done, subtracting hdr_csum (in host byte order) from csum_value (in network byte order). Despite being illegal, it generally works, because it turns out the value subtracted is (or should be) always 0, which has the same representation in either byte order. Doing illegal operations is not good form though, so fix this by verifying the IP header checksum early in that function. If its checksum is non-zero, the packet will be bad, so just return an error. This will cause the packet to passed to the IP layer where it can be dropped. Thereafter, there is no need subtract the IP header checksum from the checksum value in the trailer because we know it is zero. Add a comment explaining this. This type of packet error is different from other types, so add a new statistics counter to track this condition. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: qualcomm: rmnet: simplify rmnet_map_get_csum_field()Alex Elder1-15/+5
The checksum fields of the TCP and UDP header structures already have type __sum16. We don't support any other protocol headers, so we can simplify rmnet_map_get_csum_field(), getting rid of the local variable entirely and just returning the appropriate address. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: qualcomm: rmnet: get rid of some local variablesAlex Elder1-7/+5
The value passed as an argument to rmnet_map_ipv4_ul_csum_header() is always an IPv4 header. Rather than using a local variable, just have the type of the argument reflect the proper type. In rmnet_map_ipv6_ul_csum_header() things are defined a little differently, but make the same basic change there. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: qualcomm: rmnet: eliminate some ifdefsAlex Elder1-31/+23
If IPV6 is not enabled in the kernel configuration, the RMNet checksum code indicates a buffer containing an IPv6 packet is not supported. The same thing happens if a buffer contains something other than an IPv4 or IPv6 packet. We can rearrange things a bit in two functions so that some #ifdef calls can simply be eliminated. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: qualcomm: rmnet: use ip_is_fragment()Alex Elder1-2/+3
In rmnet_map_ipv4_dl_csum_trailer() use ip_is_fragment() to determine whether a socket buffer contains a packet fragment. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11Merge branch '100GbE' of ↵David S. Miller23-7/+2950
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== Jake Keller says: ==================== 100GbE Intel Wired LAN Driver Updates 2021-06-11 Extend the ice driver to support basic PTP clock functionality for E810 devices. This includes some tangential work required to setup the sideband queue and driver shared parameters as well. This series only supports E810-based devices. This is because other devices based on the E822 MAC use a different and more complex PHY. The low level device functionality is kept within ice_ptp_hw.c and is designed to be extensible for supporting E822 devices in a future series. This series also only supports very basic functionality including the ptp_clock device and timestamping. Support for configuring periodic outputs and external input timestamps will be implemented in a future series. There are a couple of potential "what? why?" bits in this series I want to point out: 1) the PTP hardware functionality is shared between multiple functions. This means that the same clock registers are shared across multiple PFs. In order to avoid contention or clashing between PFs, firmware assigns "ownership" to one PF, while other PFs are merely "associated" with the timer. Because we share the hardware resource, only the clock owner will allocate and register a PTP clock device. Other PFs determine the appropriate PTP clock index to report by using a firmware interface to read a shared parameter that is set by the owning PF. 2) the ice driver uses its own kthread instead of using do_aux_work. This is because the periodic and asynchronous tasks are necessary for all PFs, but only one PF will allocate the clock. The series is broken up into functional pieces to allow easy review. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11octeontx2-pf: add support for ndo_set_vf_trustHariprasad Kelam2-25/+109
Add support for setting a VF as a trusted VF by PF admin. Trusted VF feature allows VFs to perform priviliged operations such as enabling VF promiscuous mode, all-multicast mode and changing the VF MAC address even if it was assigned by PF. Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Sunil Kovvuri Goutham <Sunil.Goutham@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11octeontx2-af: add new mailbox to configure VF trust modeHariprasad Kelam5-6/+83
Add new mailbox to enable PF to configure VF as trusted VF. Trusted VF feature allows VFs to perform priviliged operations such as enabling VF promiscuous mode, all-multicast mode and changing the VF MAC address configured by PF. Refactored the VF interface flags maintained by the AF driver such that the flags do not overlap for various configurations. Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Sunil Kovvuri Goutham <Sunil.Goutham@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11octeontx2-nicvf: add ndo_set_rx_mode support for multicast & promiscNaveen Mamindlapalli1-2/+56
Add ndo_set_rx_mode callback handler to configure promisc, multicast and allmulti options for VF driver. Also, modified PF driver ndo_set_rx_mode handler to support multicast and promisc mode independently. Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Sunil Kovvuri Goutham <Sunil.Goutham@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11octeontx2-af: add support for multicast/promisc packet replication featureNaveen Mamindlapalli9-158/+482
Currently, multicast packet filtering is accomplished by installing MCAM rule that matches all-multicast MAC address and has its NPC_RX_ACTION set to unicast to PF. Similarly promisc feature is achieved by installing MCAM rule that matches all the traffic received by the channel and unicast the packets to PF. This approach only applies to PF and is not scalable across VFs. This patch adds support for PF/VF multicast and promisc feature by reserving NIX_RX_MCE_S entries from the global MCE list allocated during NIX block initialization. The NIX_RX_MCE_S entries create a linked list with a flag indicating the end of the list, and each entry points to a PF_FUNC (either PF or VF). When a packet NPC_RX_ACTION is set to MCAST, the corresponding NIX_RX_MCE_S list is traversed and the packet is queued to each PF_FUNC available on the list. The PF or VF driver adds the multicast/promisc packet match entry and updates the MCE list with correspondng PF_FUNC. When a PF or VF interface is disabled, the corresponding NIX_RX_MCE_S entry is removed from the MCE list and the MCAM entry will be disabled if the list is empty. Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Sunil Kovvuri Goutham <Sunil.Goutham@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: stmmac: Fix potential integer overflowWong Vee Khee1-1/+1
The commit d96febedfde2 ("net: stmmac: arrange Tx tail pointer update to stmmac_flush_tx_descriptors") introduced the following coverity warning:- 1. Unintentional integer overflow (OVERFLOW_BEFORE_WIDEN) overflow_before_widen: Potentially overflowing expression 'tx_q->cur_tx * desc_size' with type 'unsigned int' (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type dma_addr_t (64 bits, unsigned). Fixed this by assigning tx_tail_addr to dma_addr_t type, as dma_addr_t datatype is decided by CONFIG_ARCH_DMA_ADDR_T_64_BIT. Fixes: d96febedfde2 ("net: stmmac: arrange Tx tail pointer update to stmmac_flush_tx_descriptors") Signed-off-by: Wong Vee Khee <vee.khee.wong@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: dpaa2-mac: Add ACPI support for DPAA2 MAC driverCalvin Johnson2-37/+53
Modify dpaa2_mac_get_node() to get the dpmac fwnode from either DT or ACPI. Modify dpaa2_mac_get_if_mode() to get interface mode from dpmac_node which is a fwnode. Modify dpaa2_pcs_create() to create pcs from dpmac_node fwnode. Modify dpaa2_mac_connect() to support ACPI along with DT. Signed-off-by: Calvin Johnson <calvin.johnson@oss.nxp.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> # from the ACPI side Acked-by: Grant Likely <grant.likely@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net/fsl: Use [acpi|of]_mdiobus_registerCalvin Johnson1-9/+21
Depending on the device node type, call the specific OF or ACPI mdiobus_register function. Note: For both ACPI and DT cases, endianness of MDIO controllers need to be specified using the "little-endian" property. Signed-off-by: Calvin Johnson <calvin.johnson@oss.nxp.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Acked-by: Grant Likely <grant.likely@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: stmmac: dwmac1000: Fix extended MAC address registers definitionJisheng Zhang1-4/+4
The register starts from 0x800 is the 16th MAC address register rather than the first one. Fixes: cffb13f4d6fb ("stmmac: extend mac addr reg and fix perfect filering") Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: stmmac: Fix unused values warningsWong Vee Khee1-4/+4
The commit 8532f613bc78 ("net: stmmac: introduce MSI Interrupt routines for mac, safety, RX & TX") introduced the converity warnings:- 1. Unused value (UNUSED_VALUE) assigned_value: Assigning value REQ_IRQ_ERR_MAC to irq_err here, but that stored value is not used. 2. Unused value (UNUSED_VALUE) assigned_value: Assigning value REQ_IRQ_ERR_NO to irq_err here, but that stored value is overwritten before it can used. 3. Unused value (UNUSED_VALUE) assigned_value: Assigning value REQ_IRQ_ERR_WOL to irq_err here, but that stored value is not used. Fixed these by removing the unnecessary value assignments. Fixes: 8532f613bc78 ("net: stmmac: introduce MSI Interrupt routines for mac, safety, RX & TX") Signed-off-by: Wong Vee Khee <vee.khee.wong@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11r8169: avoid link-up interrupt issue on RTL8106e if user enables ASPMHeiner Kallweit1-1/+0
It has been reported that on RTL8106e the link-up interrupt may be significantly delayed if the user enables ASPM L1. Per default ASPM is disabled. The change leaves L1 enabled on the PCIe link (thus still allowing to reach higher package power saving states), but the NIC won't actively trigger it. Reported-by: Koba Ko <koba.ko@canonical.com> Tested-by: Koba Ko <koba.ko@canonical.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: hns3: add debugfs support for ptp infoHuazhong Tan3-2/+67
Add a debugfs interface for dumping ptp information, which is helpful for debugging. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: hns3: add support for PTPHuazhong Tan11-6/+806
Adds PTP support for HNS3 ethernet driver. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11cxgb4: halt chip before flashing PHY firmware imageRahul Lakkireddy1-3/+19
When using firmware-assisted PHY firmware image write to flash, halt the chip before beginning the flash write operation to allow the running firmware to store the image persistently. Otherwise, the running firmware will only store the PHY image in local on-chip RAM, which will be lost after next reset. Fixes: 4ee339e1e92a ("cxgb4: add support to flash PHY image") Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11cxgb4: fix sleep in atomic when flashing PHY firmwareRahul Lakkireddy3-4/+2
Before writing new PHY firmware to on-chip memory, driver queries firmware for current running PHY firmware version, which can result in sleep waiting for reply. So, move spinlock closer to the actual on-chip memory write operation, instead of taking it at the callers. Fixes: 5fff701c838e ("cxgb4: always sync access when flashing PHY firmware") Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11cxgb4: fix endianness when flashing boot imageRahul Lakkireddy1-17/+27
Boot images are copied to memory and updated with current underlying device ID before flashing them to adapter. Ensure the updated images are always flashed in Big Endian to allow the firmware to read the new images during boot properly. Fixes: 550883558f17 ("cxgb4: add support to flash boot image") Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11alx: Fix an error handling path in 'alx_probe()'Christophe JAILLET1-0/+1
If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: ab69bde6b2e9 ("alx: add a simple AR816x/AR817x device driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11ice: enable transmit timestamps for E810 devicesJacob Keller9-4/+518
Add support for enabling Tx timestamp requests for outgoing packets on E810 devices. The ice hardware can support multiple outstanding Tx timestamp requests. When sending a descriptor to hardware, a Tx timestamp request is made by setting a request bit, and assigning an index that represents which Tx timestamp index to store the timestamp in. Hardware makes no effort to synchronize the index use, so it is up to software to ensure that Tx timestamp indexes are not re-used before the timestamp is reported back. To do this, introduce a Tx timestamp tracker which will keep track of currently in-use indexes. In the hot path, if a packet has a timestamp request, an index will be requested from the tracker. Unfortunately, this does require a lock as the indexes are shared across all queues on a PHY. There are not enough indexes to reliably assign only 1 to each queue. For the E810 devices, the timestamp indexes are not shared across PHYs, so each port can have its own tracking. Once hardware captures a timestamp, an interrupt is fired. In this interrupt, trigger a new work item that will figure out which timestamp was completed, and report the timestamp back to the stack. This function loops through the Tx timestamp indexes and checks whether there is now a valid timestamp. If so, it clears the PHY timestamp indication in the PHY memory, locks and removes the SKB and bit in the tracker, then reports the timestamp to the stack. It is possible in some cases that a timestamp request will be initiated but never completed. This might occur if the packet is dropped by software or hardware before it reaches the PHY. Add a task to the periodic work function that will check whether a timestamp request is more than a few seconds old. If so, the timestamp index is cleared in the PHY, and the SKB is released. Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and use the same overall logic for extending to 64 bits of nanoseconds. With this change, E810 devices should be able to perform basic PTP functionality. Future changes will extend the support to cover the E822-based devices. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-11ice: enable receive hardware timestampingJacob Keller9-6/+410
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to requests to enable timestamping support. If the request is for enabling Rx timestamps, set a bit in the Rx descriptors to indicate that receive timestamps should be reported. Hardware captures receive timestamps in the PHY which only captures part of the timer, and reports only 40 bits into the Rx descriptor. The upper 32 bits represent the contents of GLTSYN_TIME_L at the point of packet reception, while the lower 8 bits represent the upper 8 bits of GLTSYN_TIME_0. The networking and PTP stack expect 64 bit timestamps in nanoseconds. To support this, implement some logic to extend the timestamps by using the full PHC time. If the Rx timestamp was captured prior to the PHC time, then the real timestamp is PHC - (lower_32_bits(PHC) - timestamp) If the Rx timestamp was captured after the PHC time, then the real timestamp is PHC + (timestamp - lower_32_bits(PHC)) These calculations are correct as long as neither the PHC timestamp nor the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can detect when the Rx timestamp is before or after the PHC as long as the PHC timestamp is no more than 2^31-1 nanoseconds old. In that case, we calculate the delta between the lower 32 bits of the PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx timestamp must have been captured in the past. If it's smaller, then the Rx timestamp must have been captured after PHC time. Add an ice_ptp_extend_32b_ts function that relies on a cached copy of the PHC time and implements this algorithm to calculate the proper upper 32bits of the Rx timestamps. Cache the PHC time periodically in all of the Rx rings. This enables each Rx ring to simply call the extension function with a recent copy of the PHC time. By ensuring that the PHC time is kept up to date periodically, we ensure this algorithm doesn't use stale data and produce incorrect results. To cache the time, introduce a kworker and a kwork item to periodically store the Rx time. It might seem like we should use the .do_aux_work interface of the PTP clock. This doesn't work because all PFs must cache this time, but only one PF owns the PTP clock device. Thus, the ice driver will manage its own kthread instead of relying on the PTP do_aux_work handler. With this change, the driver can now report Rx timestamps on all incoming packets. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-11ice: report the PTP clock index in ethtool .get_ts_infoJacob Keller3-1/+155
Now that the driver registers a PTP clock device that represents the clock hardware, it is important that the clock index is reported via the ethtool .get_ts_info callback. The underlying hardware resource is shared between multiple PF functions. Only one function owns the hardware resources associated with a timer, but multiple functions may be associated with it for the purposes of timestamping. To support this, the owning PF will store the clock index into the driver shared parameters buffer in firmware. Other PFs will look up the clock index by reading the driver shared parameter on demand when requested via the .get_ts_info ethtool function. In this way, all functions which are tied to the same timer are able to report the clock index. Userspace software such as ptp4l performs a look up on the netdev to determine the associated clock, and all commands to control or configure the clock will be handled through the controlling PF. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-11ice: register 1588 PTP clock device object for E810 devicesJacob Keller8-0/+513
Add a new ice_ptp.c file for holding the basic PTP clock interface functions. If the device supports PTP, call the new ice_ptp_init and ice_ptp_release functions where appropriate. If the function owns the hardware resource associated with the PTP hardware clock, register with the PTP_1588_CLOCK infrastructure to allocate a new clock object that represents the device hardware clock. Implement basic functionality for reading and setting the clock time, performing clock adjustments, and adjusting the clock frequency. Future changes will introduce functionality for handling related features including Tx and Rx timestamps. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-11ice: add low level PTP clock access functionsJacob Keller4-0/+758
Add the ice_ptp_hw.c file and some associated definitions to the ice driver folder. This file contains basic low level definitions for functions that interact with the device hardware. For now, only E810-based devices are supported. The ice hardware supports 2 major variants which have different PHYs with different procedures necessary for interacting with the device clock. Because the device captures timestamps in the PHY, each PHY has its own internal timer. The timers are synchronized in hardware by first preparing the source timer and the PHY timer shadow registers, and then issuing a synchronization command. This ensures that both the source timer and PHY timers are programmed simultaneously. The timers themselves are all driven from the same oscillator source. The functions in ice_ptp_hw.c abstract over the differences between how the PHYs in E810 are programmed vs how the PHYs in E822 devices are programmed. This series only implements E810 support, but E822 support will be added in a future change. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-11ice: add support for set/get of driver-stored firmware parametersJacob Keller3-0/+108
Depending on the device configuration, the ice hardware may share the PTP hardware clock timer between multiple PFs. Each PF is informed by firmware during initialization of the PTP timer association. When bringing up PTP, only the PFs which own the timer shall allocate a PTP hardware clock. Other PFs associated with that timer must report the correct PTP clock index in order to allow userspace software the ability to know which ports are connected to the same clock. To support this, the firmware has driver shared parameters. These parameters enable one PF to write the clock index into firmware, and have other PFs read the associated value out. This enables the driver to have only a single PF allocate and control the device timer registers, while other PFs associated with that timer can report the correct clock in the ETHTOOL_GET_TS_INFO report. Add support for the necessary admin queue commands to enable reading and writing of the driver shared parameters. This will be used in a future change to enable sharing the PTP clock index between PF drivers. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-11ice: process 1588 PTP capabilities during initializationJacob Keller3-0/+151
The device firmware reports PTP clock capabilities to each PF during initialization. This includes various information for both the overall device and the individual function, including For functions: * whether this function has timesync enabled * whether this function owns one of the 2 possible clock timers, and which one * which timer the function is associated with * the clock frequency, if the device supports multiple clock frequencies * The GPIO pin association for the timer owned by this PF, if any For the device: * Which PF owns timer 0, if any * Which PF owns timer 1, if any * whether timer 0 is enabled * whether timer 1 is enabled Extract the bits from the capabilities information reported by firmware and store them in the device and function capability structures.o This information will be used in a future change to have the function driver enable PTP hardware clock support. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-11ice: add support for sideband messagesJacob Keller11-2/+343
In order to support certain device features, including enabling the PTP hardware clock, the ice driver needs to control some registers on the device PHY. These registers are accessed by sending sideband messages. For some hardware, these messages must be sent over the device admin queue, while other hardware has a dedicated control queue for the sideband messages. Add the neighbor device message structure for sending a message to the neighboring device. Where supported, initialize the sideband control queue and handle cleanup. Add a wrapper function for sending sideband control queue messages that read or write a neighboring device register. Because some devices send sideband messages over the AdminQ, also increase the length of the admin queue to allow more messages to be queued up. This is important because the sideband messages add additional pressure on the AQ usage. This support will be used in following patches to enable support for CONFIG_1588_PTP_CLOCK. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-11ibmvnic: Allow device probe if the device is not ready at bootCristobal Forno2-27/+132
Allow the device to be initialized at a later time if it is not available at boot. The device will be allowed to probe but will be given a "down" state. After completing device probe and registering the net device, the driver will await an interrupt signal from its partner device, indicating that it is ready for boot. The driver will schedule a work event to perform the necessary procedure and begin operation. Co-developed-by: Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by: Cristobal Forno <cforno12@linux.ibm.com> Acked-by: Lijun Pan <lijunp213@gmail.com> Reviewed-by: Dany Madden <drt@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: marvell: prestera: add LAG supportSerhiy Boiko5-31/+531
The following features are supported: - LAG basic operations - create/delete LAG - add/remove a member to LAG - enable/disable member in LAG - LAG Bridge support - LAG VLAN support - LAG FDB support Limitations: - Only HASH lag tx type is supported - The Hash parameters are not configurable. They are applied during the LAG creation stage. - Enslaving a port to the LAG device that already has an upper device is not supported. Co-developed-by: Andrii Savka <andrii.savka@plvision.eu> Signed-off-by: Andrii Savka <andrii.savka@plvision.eu> Signed-off-by: Serhiy Boiko <serhiy.boiko@plvision.eu> Co-developed-by: Vadym Kochan <vkochan@marvell.com> Signed-off-by: Vadym Kochan <vkochan@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: marvell: prestera: do not propagate netdev events to prestera_switchdev.cVadym Kochan3-37/+19
Replace prestera_bridge_port_event(...) by prestera_bridge_port_join(...) and prestera_bridge_port_leave(). It simplifies the code by reading netdev event specific handling only once in prestera_main.c Signed-off-by: Vadym Kochan <vkochan@marvell.com> CC: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11net: marvell: prestera: move netdev topology validation to prestera_mainVadym Kochan2-23/+26
Move handling of PRECHANGEUPPER event from prestera_switchdev to prestera_main which is responsible for basic netdev events handling and routing them to related module. Signed-off-by: Vadym Kochan <vkochan@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11ibmvnic: Use list_for_each_entry() to simplify code in ibmvnic.cWang Hai1-2/+1
Convert list_for_each() to list_for_each_entry() where applicable. This simplifies the code. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Acked-by: Lijun Pan <lijunp213@gmail.com> Reviewed-by: Dany Madden <drt@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10net: stmmac: Fix mixed enum type warningWong Vee Khee1-2/+2
The commit 5a5586112b92 ("net: stmmac: support FPE link partner hand-shaking procedure") introduced the following coverity warning: "Parse warning (PW.MIXED_ENUM_TYPE)" "1. mixed_enum_type: enumerated type mixed with another type" This is due to both "lo_state" and "lp_sate" which their datatype are enum stmmac_fpe_state type, and being assigned with "FPE_EVENT_UNKNOWN" which is a macro-defined of 0. Fixed this by assigned both these variables with the correct enum value. Fixes: 5a5586112b92 ("net: stmmac: support FPE link partner hand-shaking procedure") Signed-off-by: Wong Vee Khee <vee.khee.wong@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10net: axienet: Use devm_platform_get_and_ioremap_resource()Yang Yingliang1-5/+2
Use devm_platform_get_and_ioremap_resource() to simplify code. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10net: w5100: Use devm_platform_get_and_ioremap_resource()Yang Yingliang1-6/+1
Use devm_platform_get_and_ioremap_resource() to simplify code. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10Merge tag 'mlx5-fixes-2021-06-09' of ↵David S. Miller16-72/+111
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5-fixes-2021-06-09 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10Merge tag 'mlx5-updates-2021-06-09' of ↵David S. Miller26-120/+2373
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5-updates-2021-06-09 Introduce steering header insert/remove and switchdev bridge offloads 1) From Yevgeny, Steering header insert/remove support ConnectX supports offloading of various encapsulations and decapsulations (e.g. VXLAN), which are performed by 'Packet Reformat' action. Starting with ConnectX-6 DX, a new reformat type is supported - INSERT_HEADER. This reformat allows inserting an arbitrary size buffer at a selected location in the packet on RX flows. The insert/remove header support are needed as a prerequisite for the bridge offloads vlan pop/push supprt, see below. 2) From Vlad, Support for bridge offloads for switchdev mode This change implements bridge offloads with VLAN-support that works on top of mlx5 representors in switchdev mode. HIGH-LEVEL OVERVIEW Hardware supported by mlx5 driver doesn't provide dynamic learning or aging functionality and requires the driver to emulate all switch-like behavior in software. As such, all packets by default go through miss path, appear on representor and get to software bridge, if it is the upper device of the representor. This causes bridge to process packet in software, learn the MAC address to FDB and send SWITCHDEV_FDB_ADD_TO_DEVICE event to all subscribers. Upon reception of SWITCHDEV_FDB_ADD_TO_DEVICE notification mlx5 bridge offloads the FDB to hardware and sends back SWITCHDEV_FDB_ADD_TO_BRIDGE notification to prevent such entries from being aged out by kernel bridge. Leaving aging to kernel bridge would result deletion of offloaded dynamic FDB entries every aging_time period due to packets being processed by hardware and, consecutively, 'used' timestamp for FDB entry not being updated. Hardware aging is emulated in driver by running periodic workqueue task that manually updates the rules according to their hardware counter: - If hardware counter has changed since last update, the handler updates 'used' timestamp in kernel bridge dynamic entry by sending SWITCHDEV_FDB_ADD_TO_BRIDGE notification for the entry. - If FDB entry wasn't updated for user-controllable aging_time period, then the FDB entry is unoffloaded from hardware and corresponding SWITCHDEV_FDB_DEL_TO_BRIDGE notification is sent to kernel bridge. The mlx5 bridge offload implementation fully supports port VLAN objects, including PVID (vlan push) and "Egress Untagged" (vlan pop). SOFTWARE ARCHITECTURE Mlx5_eswitch is extended with pointer to new mlx5_esw_bridge_offloads structure which has a linked list of mlx5_esw_bridge objects. Struct mlx5_esw_bridge is the main switch object in mlx5 that holds all data for offloaded FDB entries and metadata for bridge ports and their vlans. The mlx5_esw_bridge object is created when first representor of eswitch vport is added to bridge and deleted when the last representor is detached from it. Bridge FDB entries are saved in linked list (to iterate over all FDB entries in aging workqueue task) and also in hashtable for quick lookup by MAC+VLAN tuple. Bridge FDB entries are saved in linked list (to iterate over all FDB entries in aging workqueue task) and in hashtable for quick lookup by MAC+VLAN tuple. Port metadata is stored in struct mlx5_esw_bridge_port that is saved in xarray to allow quick lookup by vport number. Part of the port metadata is the set of port vlans that are represented by mlx5_esw_bridge_vlan structure. The vlan structure points to all FDBs on vlan/port via fdb_list linked list. Simplified diagram of mlx5 bridge objects: +------------------+ | mxl5_eswitch | | | | br_offloads | +--------+---------+ | +--------v-------------------+ | mlx5_esw_bridge_offloads | | | +--> bridges | | +-------+--------------------+ | | | | | +---v---------------+ | | mlx5_esw_bridge | | | | | | vports | | | | | | fdb_ht | | +---+---------------+ | | | +---v---------------+ +------+ mlx5_esw_bridge | | | +-------------------------+ vports | | | | | | fdb_ht +------------------------------------------+ | +-------------------+ | | | | | | +----------------------+ +---------------------------+ | +-> mlx5_esw_bridge_port | +--> mlx5_esw_bridge_fdb_entry <-+ | | | +----------------------+ | +--+------------------------+ | | | vlans +--+-> mlx5_esw_bridge_vlan | | | | | | | | | | | +--v------------------------+ | | +----------------------+ | | fdb_list +--+ | mlx5_esw_bridge_fdb_entry <-+ | | +-------^--------------+ +--+------------------------+ | | +----------------------+ | | | | +-> mlx5_esw_bridge_port | | +-----------------------+ | | | | | | vlans | | -----------------------+ | | | +-> mlx5_esw_bridge_vlan | | +----------------------+ | | +---------------------------+ | | fdb_list +-----> mlx5_esw_bridge_fdb_entry <-+ +-------^--------------+ +--+------------------------+ | | +-----------------------+ HARDWARE REPRESENTATION In order to adhere to kernel software datapath model bridge offloads must come after TC and NF FDBs. However, since netfilter offload in mlx5 is implemented with unmanaged tables, its miss path is not automatically connected to next priority and requires the code to manually connect with slow table. To keep bridge offloads encapsulated and not mix it with eswitch offloads new FDB_TC_MISS priority is created between FDB_FT_OFFLOAD and FDB_SLOW_PATH which allows bridge offloads to be created without exposing its internal tables to any other modules since miss path of managed TC-miss table is automatically wired to next priority. The bridge tables are created with new priority FDB_BR_OFFLOAD in FDB namespace. The new priority is between tc-miss and slow path priorities. Priority consist of two levels: the ingress table that is global per eswitch and matches incoming packets by src_mac/vid and redirects them to next level (egress table) that is chosen according to ingress port bridge membership and matches on dst_mac/vid in order to redirect packet to vport according to the following diagram: + | +---------v----------+ | | | FDB_TC_OFFLOAD | | | +---------+----------+ | | +---------v----------+ | | | FDB_FT_OFFLOAD | | | +---------+----------+ | | +---------v----------+ | | | FDB_TC_MISS | | | +---------+----------+ | +--------------------------------------+ | | | | +------+ | | | | | +------v--------+ FDB_BR_OFFLOAD | | | INGRESS_TABLE | | | +------+---+----+ | | | | match | | | +---------+ | | | | | +-------+ | | +-------v-------+ match | | | | | | EGRESS_TABLE +------------> vport | | | +-------+-------+ | | | | | | | +-------+ | | miss | | | +------+------+ | | | | +--------------------------------------+ | | +---------v----------+ | | | FDB_SLOW_PATH | | | +---------+----------+ | v PATCHES OVERVIEW 1-3 - Miscellaneous refactorings and infrastructure changes. 4 - Mlx5 bridge offload infrastructure and dedicated fs_core namespace/tables implementation. 5 - FDB entry offload. 6 - Dynamic FDB entry aging. 7-10 - VLAN filtering offload. 11 - Tracepoints for main mlx5 bridge offload events (FDB entry offload/unoffload, VLAN add/delete, etc.) ==================== Signed-off-by: David S. Miller <davem@davemloft.net> --
2021-06-10net: davinci_emac: Use devm_platform_get_and_ioremap_resource()Yang Yingliang1-3/+2
Use devm_platform_get_and_ioremap_resource() to simplify code and avoid a null-ptr-deref by checking 'res' in it. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10net: ethernet: ti: cpsw: Use devm_platform_get_and_ioremap_resource()Yang Yingliang2-4/+2
Use devm_platform_get_and_ioremap_resource() to simplify code. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaLinus Torvalds3-0/+10
Pull rdma fixes from Jason Gunthorpe: "A mixture of small bug fixes and a small security issue: - WARN_ON when IPoIB is automatically moved between namespaces - Long standing bug where mlx5 would use the wrong page for the doorbell recovery memory if fork is used - Security fix for mlx4 that disables the timestamp feature - Several crashers for mlx5 - Plug a recent mlx5 memory leak for the sig_mr" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: IB/mlx5: Fix initializing CQ fragments buffer RDMA/mlx5: Delete right entry from MR signature database RDMA: Verify port when creating flow rule RDMA/mlx5: Block FDB rules when not in switchdev mode RDMA/mlx4: Do not map the core_clock page to user space unless enabled RDMA/mlx5: Use different doorbell memory for different processes RDMA/ipoib: Fix warning caused by destroying non-initial netns
2021-06-10net/mlx5: Bridge, add tracepointsVlad Buslov3-50/+191
Move private bridge structures to dedicated headers that is accessible to bridge tracepoint header. Implemented following tracepoints: - Initialize FDB entry. - Refresh FDB entry. - Cleanup FDB entry. - Create VLAN. - Cleanup VLAN. - Attach port to bridge. - Detach port from bridge. Usage example: ># cd /sys/kernel/debug/tracing ># echo mlx5:mlx5_esw_bridge_fdb_entry_init >> set_event ># cat trace ... kworker/u20:1-96 [001] .... 231.892503: mlx5_esw_bridge_fdb_entry_init: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=3 flags=0 lastuse=4294895695 Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-10net/mlx5: Bridge, filter tagged packets that didn't match tagged fgVlad Buslov3-5/+141
With support for pvid vlans in mlx5 bridge it is possible to have rules in untagged flow group when vlan filtering is enabled. However, such rules can also match tagged packets that didn't match anything in tagged flow group. Filter such packets by introducing additional flow group between tagged and untagged groups. When filtering is enabled on the bridge create additional flow in vlan filtering flow group and matches tagged packets with specified source MAC address and redirects them to new "skip" table. The skip table is new lowest-level empty table that is used to skip all further processing on packet in bridge priority. Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-06-10net/mlx5: Bridge, support pvid and untagged vlan configurationsVlad Buslov1-16/+159
Implement support for pushing vlan header into untagged packet on ingress of port that has pvid configured and support for popping vlan on egress of port that has the matching vlan configured as untagged. To support such configurations packet reformat contexts of {INSERT|REMOVE}_HEADER types are created per such vlan and saved to struct mlx5_esw_bridge_vlan which allows all FDB entries on particular vlan to share single packet reformat instance. When initializing FDB entries with pvid or untagged vlan type set its mlx5_flow_act->pkt_reformat action accordingly. Flush all flows when removing vlan from port. This is necessary because even though software bridge removes all FDB entries before removing their vlan, mlx5 bridge implementation deletes their corresponding flow entries from hardware in asynchronous workqueue task, which will cause firmware error if vlan packet reformat context is deleted before all flows that point to it. Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>