- 19 Mar, 2021 40 commits
-
-
David S. Miller authored
Bjarni Jonasson says: ==================== Fixes applied to VCS8584 family Three different fixes applied to VSC8584 family: 1. LCPLL reset 2. Serdes calibration 3. Coma mode disabled The same fixes has already been applied to VSC8514 and most of the functionality can be reused for the VSC8584. v1 -> v2: Preserved reversed christmas tree ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjarni Jonasson authored
This patch releases coma mode for VSC8584 as done for VSC8514 in commit ca0d7fd0 ("net: phy: mscc: coma mode disabled for VSC8514") Fixes: a5afc167 ("net: phy: mscc: add support for VSC8584 PHY.") Signed-off-by: Bjarni Jonasson <bjarni.jonasson@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjarni Jonasson authored
Introduced 'FOJI' serdes calibration in commit 85e97f0b ("net: phy: mscc: improved serdes calibration applied to VSC8514") Now including the VSC8584 family. Fixes: a5afc167 ("net: phy: mscc: add support for VSC8584 PHY.") Signed-off-by: Bjarni Jonasson <bjarni.jonasson@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjarni Jonasson authored
Introduced LCPLL reset in commit d15e08d9fb82 ("net: phy: mscc: adding LCPLL reset to VSC8514"). Now applying this reset to the VSC8584 phy familiy. Fixes: a5afc167 ("net: phy: mscc: add support for VSC8584 PHY.") Signed-off-by: Bjarni Jonasson <bjarni.jonasson@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
Michael reports that after the blamed patch, unbinding a VF would cause these transactions to remain pending, and trigger some warnings with the DMA API debug: $ echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001 fsl_enetc_vf 0000:00:01.0: Adding to iommu group 19 fsl_enetc_vf 0000:00:01.0: enabling device (0000 -> 0002) fsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0 $ echo 0 > /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs DMA-API: pci 0000:00:01.0: device driver has pending DMA allocations while released from device [count=1] One of leaked entries details: [size=2048 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent] WARNING: CPU: 0 PID: 2547 at kernel/dma/debug.c:853 dma_debug_device_change+0x174/0x1c8 (...) Call trace: dma_debug_device_change+0x174/0x1c8 blocking_notifier_call_chain+0x74/0xa8 device_release_driver_internal+0x18c/0x1f0 device_release_driver+0x20/0x30 pci_stop_bus_device+0x8c/0xe8 pci_stop_and_remove_bus_device+0x20/0x38 pci_iov_remove_virtfn+0xb8/0x128 sriov_disable+0x3c/0x110 pci_disable_sriov+0x24/0x30 enetc_sriov_configure+0x4c/0x108 sriov_numvfs_store+0x11c/0x198 (...) DMA-API: Mapped at: dma_entry_alloc+0xa4/0x130 debug_dma_alloc_coherent+0xbc/0x138 dma_alloc_attrs+0xa4/0x108 enetc_setup_cbdr+0x4c/0x1d0 enetc_vf_probe+0x11c/0x250 pci 0000:00:01.0: Removing from iommu group 19 This happens because stupid me moved enetc_teardown_cbdr outside of enetc_free_si_resources, but did not bother to keep calling enetc_teardown_cbdr from all the places where enetc_free_si_resources was called. In particular, now it is no longer called from the main unbind function, just from the probe error path. Fixes: 4b47c0b8 ("net: enetc: don't initialize unused ports from a separate code path") Reported-by: Michael Walle <michael@walle.cc> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
There is a spelling mistake in an error message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wei Yongjun authored
The driver allocates the spinlock but not initialize it. Use spin_lock_init() on it to initialize it correctly. Fixes: d8ce30e0 ("octeontx2-pf: add tc flower stats handler for hw offloads") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Use the lower_32_bits/upper_32_bits macros to simplify the code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c: In function ‘mgmt_recv_msg_handler’: drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c:443:18: warning: unused variable ‘pdev’ [-Wunused-variable] 443 | struct pci_dev *pdev = pf_to_mgmt->hwif->pdev; | ^~~~ Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Daode Huang says: ==================== net: hinic; make some cleanup for hinic This set try to remove the unnecessary output message, add a blank line, remove the dupliate word and change the deprecated strlcp functions in hinic driver, for details, please refer to each patch. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daode Huang authored
Usage of strlcpy in linux kernel has been recently deprecated[1], so convert hinic driver to strscpy [1] https://lore.kernel.org/lkml/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL =V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Daode Huang <huangdaode@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daode Huang authored
There is a duplicate "the" in the comment, so delete it. Signed-off-by: Daode Huang <huangdaode@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daode Huang authored
There should be a blank line after declarations, so just add it. Signed-off-by: Daode Huang <huangdaode@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daode Huang authored
This patch removes unnecessary out of memory message in hinic driver, fixes the following checkpatch.pl warning: "WARNING: Possible unnecessary 'out of memory' message" Signed-off-by: Daode Huang <huangdaode@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sieng Piaw Liew authored
Using napi_alloc_skb in NAPI context avoids enable/disable IRQs, which increases iperf3 result by a few Mbps. Since napi_alloc_skb() uses NET_IP_ALIGN, convert other alloc methods to the same padding. Tested on Intel Core2 and AMD K10 platforms. Signed-off-by: Sieng Piaw Liew <liew.s.piaw@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sieng Piaw Liew authored
Changing to napi_gro_receive() improves efficiency significantly. Tested on Intel Core2-based motherboards and iperf3. Signed-off-by: Sieng Piaw Liew <liew.s.piaw@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michael Walle authored
Here is what Vladimir says about it: at803x_aneg_done() keeps the aneg reporting as "not done" even when the copper-side link was reported as up, but the in-band autoneg has not finished. That was the _intended_ behavior when that code was introduced, and Heiner have said about it [1]: | That's not nice from the PHY: | It signals "link up", and if the system asks the PHY for link details, | then it sheepishly says "well, link is *almost* up". If the specification of phy_aneg_done behavior does not include in-band autoneg (and it doesn't), then this piece of code does not belong here. The fact that we can no longer trigger this code from phylib is yet another reason why it fails at its intended (and wrong) purpose and should be removed. Removing the SGMII link check, would just keep the call to genphy_aneg_done(), which is also the fallback. Thus we can just remove at803x_aneg_done() altogether. [1] https://lore.kernel.org/netdev/fdf0074a-2572-5914-6f3e-77202cbf96de@gmail.com/Suggested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kurt Kanzenbach authored
When using short intervals e.g. below one millisecond, large packets won't be transmitted at all. The software implementations checks whether the packet can be fit into the remaining interval. Therefore, it takes the packet length and the transmission speed into account. That is correct. However, for large packets it may be that the transmission time exceeds the interval resulting in no packet transmission. The same situation works fine with hardware offloading applied. The problem has been observed with the following schedule and iperf3: |tc qdisc replace dev lan1 parent root handle 100 taprio \ | num_tc 8 \ | map 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 \ | queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \ | base-time $base \ | sched-entry S 0x40 500000 \ | sched-entry S 0xbf 500000 \ | clockid CLOCK_TAI \ | flags 0x00 [...] |root@tsn:~# iperf3 -c 192.168.2.105 |Connecting to host 192.168.2.105, port 5201 |[ 5] local 192.168.2.121 port 52610 connected to 192.168.2.105 port 5201 |[ ID] Interval Transfer Bitrate Retr Cwnd |[ 5] 0.00-1.00 sec 45.2 KBytes 370 Kbits/sec 0 1.41 KBytes |[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes After debugging, it seems that the packet length stored in the SKB is about 7000-8000 bytes. Using a 100 Mbit/s link the transmission time is about 600us which larger than the interval of 500us. Therefore, segment the SKB into smaller chunks if the packet is too big. This yields similar results than the hardware offload: |root@tsn:~# iperf3 -c 192.168.2.105 |Connecting to host 192.168.2.105, port 5201 |- - - - - - - - - - - - - - - - - - - - - - - - - |[ ID] Interval Transfer Bitrate Retr |[ 5] 0.00-10.00 sec 48.9 MBytes 41.0 Mbits/sec 0 sender |[ 5] 0.00-10.02 sec 48.7 MBytes 40.7 Mbits/sec receiver Furthermore, the segmentation can be skipped for the full offload case, as the driver or the hardware is expected to handle this. Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bhaskar Chowdhury authored
s/verfied/verified/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Alexander Lobakin says: ==================== net: avoid retpoline overhead on VLAN and TEB GRO dev_gro_receive() uses indirect calls for IP GRO functions, but it works only for the outermost headers and untagged frames. Simple VLAN tag before an IP header restores the performance hit. This simple series straightens the GRO calls for IP headers going after VLAN tag or inner Ethernet header (GENEVE, NvGRE, VxLAN) for retpolined kernels. ====================
-
Alexander Lobakin authored
The two most popular headers going after Ethernet are IPv4 and IPv6. Retpoline overhead for them is addressed only in dev_gro_receive(), when they lie right after the outermost Ethernet header. Use the indirect call wrappers in TEB (Transparent Ethernet Bridging, such as GENEVE, NvGRE, VxLAN etc.) GRO receive code to reduce the penalty when processing the inner headers. Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Lobakin authored
The two most popular headers going after VLAN are IPv4 and IPv6. Retpoline overhead for them is addressed only in dev_gro_receive(), when they lie right after the outermost Ethernet header. Use the indirect call wrappers in VLAN GRO receive code to reduce the penalty on receiving tagged frames (when hardware stripping is off or not available). Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Lobakin authored
call_gro_receive() is used to limit GRO recursion, but it works only with callback pointers. There's a combined version of call_gro_receive() + INDIRECT_CALL_2() in <net/inet_common.h>, but it doesn't check for IPv6 modularity. Add a similar new helper to cover both of these. It can and will be used to avoid retpoline overhead when IP header lies behind another offloaded proto. Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Lobakin authored
If some source file includes <net/gro.h>, but doesn't include <linux/indirect_call_wrapper.h>: In file included from net/8021q/vlan_core.c:7: ./include/net/gro.h:6:1: warning: data definition has no type or storage class 6 | INDIRECT_CALLABLE_DECLARE(struct sk_buff *ipv6_gro_receive(struct list_head *, | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./include/net/gro.h:6:1: error: type defaults to ‘int’ in declaration of ‘INDIRECT_CALLABLE_DECLARE’ [-Werror=implicit-int] [...] Include <linux/indirect_call_wrapper.h> directly. It's small and won't pull lots of dependencies. Also add some incomplete struct declarations to be fully stacked. Fixes: 04f00ab2 ("net/core: move gro function declarations to separate header ") Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bhaskar Chowdhury authored
s/serisouly/seriously/ ...and the sentence construction. Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Shannon Nelson says: ==================== ionic fixes These are a few little fixes and cleanups found while working on other features and more testing. ====================
-
Shannon Nelson authored
Don't destroy the adminq while there is an outstanding request. Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Up to now we've been ignoring any error return from the queue starting in the link status check, so we fix that here. If the driver had to reset and couldn't get things running properly again, for example after a Tx Timeout and the FW is not responding to commands, don't let the link watchdog try to restart the queues. At this point the user can try to DOWN and UP the device to clear the errors. Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Block some actions while the FW is in a reset activity and the queues are not configured. Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Add support in get_link_ksettings for a couple of new BASET connections. Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
We can get to the counter without going through the pointer that the robot complained about. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
The qcq->intr.index was set when the queue was allocated, there is no need to reach around to find it. Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Catch a couple of missing macro name uses, fix a couple of misspellings, etc. Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
The ocelot switches are a bit odd in that they do not have an STP state to put the ports into. Instead, the forwarding configuration is delayed from the typical port_bridge_join into stp_state_set, when the port enters the BR_STATE_FORWARDING state. I can only guess that the implementation of this quirk is the reason that led to the simplification of the driver such that only one bridge could be offloaded at a time. We can simplify the data structures somewhat, and introduce a per-port bridge device pointer and STP state, similar to how the LAG offload works now (there we have a per-port bonding device pointer and TX enabled state). This allows offloading multiple bridges with relative ease, while still keeping in place the quirk to delay the programming of the PGIDs. We actually need this change now because we need to remove the bogus restriction from ocelot_bridge_stp_state_set that ocelot->bridge_mask needs to contain BIT(port), otherwise that function is a no-op. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Horatiu Vultur authored
When a MRP ring was deleted or disabled, the driver was iterating over the ports to detect if any other MPR rings exists and in case it didn't exist it would delete the MAC table entry. But the problem was that it used the last iterated port to delete the MAC table entry and this could be a NULL port. The fix consists of using the port on which the function was called. Fixes: 7c588c3e ("net: ocelot: Extend MRP") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xie He authored
When a virtual LAPB device's underlying Ethernet device closes, the LAPB device is also closed. However, currently the LAPB device is closed after the Ethernet device closes. It would be better to close it before the Ethernet device closes. This would allow the LAPB device to transmit a last frame to notify the other side that it is disconnecting. Signed-off-by: Xie He <xie.he.0141@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
The pointer pfvf is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Fixes: 56bcef52 ("octeontx2-af: Use npc_install_flow API for promisc and broadcast entries") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Johan Hovold authored
The driver data for the data interface has already been set by usb_driver_claim_interface() so drop the subsequent redundant assignment. Note that this also avoids setting the driver data three times in case of a combined interface. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
zuoqilin authored
Simplify the return expression. Signed-off-by: zuoqilin <zuoqilin@yulong.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xiong Zhenwu authored
A typo is found out by codespell tool in 1734th line of drop_monitor.c: $ codespell ./net/core/ ./net/core/drop_monitor.c:1734: guarnateed ==> guaranteed Fix a typo found by codespell. Signed-off-by: Xiong Zhenwu <xiong.zhenwu@zte.com.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
-