- 19 Mar, 2021 34 commits
-
-
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>
-
Xiong Zhenwu authored
A typo is found out by codespell tool in 111th line of hsr_debugfs.c: $ codespell ./net/hsr/ net/hsr/hsr_debugfs.c:111: Debufs ==> Debugfs Fix typos found by codespell. Signed-off-by: Xiong Zhenwu <xiong.zhenwu@zte.com.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/of/of_net.c:104: warning: Function parameter or member 'np' not described in 'of_get_mac_address' drivers/of/of_net.c:104: warning: expecting prototype for mac(). Prototype was for of_get_mac_address() instead Cc: Andrew Lunn <andrew@lunn.ch> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: netdev@vger.kernel.org Cc: devicetree@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wong, Vee Khee authored
Intel mGbE variant implemented in EHL and TGL can be set to select different clock frequency based on GPO bits in MAC_GPIO_STATUS register. We introduce a new "void (*ptp_clk_freq_config)(void *priv)" in platform data so that if a platform is required to configure the frequency of clock source, in this case Intel mGBE does, the platform-specific configuration of the PTP clock setting is done when stmmac_ptp_register() is called. Signed-off-by: Wong, Vee Khee <vee.khee.wong@intel.com> Signed-off-by: Voon Weifeng <weifeng.voon@intel.com> Co-developed-by: Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 18 Mar, 2021 6 commits
-
-
David S. Miller authored
Tobias Waldekranz says: ==================== net: dsa: mv88e6xxx: Offload bridge port flags Add support for offloading learning and broadcast flooding flags. With this in place, mv88e6xx supports offloading of all bridge port flags that are currently supported by the bridge. Broadcast flooding is somewhat awkward to control as there is no per-port bit for this like there is for unknown unicast and unknown multicast. Instead we have to update the ATU entry for the broadcast address for all currently used FIDs. v2 -> v3: - Only return a netdev from dsa_port_to_bridge_port if the port is currently bridged (Vladimir & Florian) v1 -> v2: - Ensure that mv88e6xxx_vtu_get handles VID 0 (Vladimir) - Fixed off-by-one in mv88e6xxx_port_set_assoc_vector (Vladimir) - Fast age all entries on port when disabling learning (Vladimir) - Correctly detect bridge flags on LAG ports (Vladimir) ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tobias Waldekranz authored
These switches have two modes of classifying broadcast: 1. Broadcast is multicast. 2. Broadcast is its own unique thing that is always flooded everywhere. This driver uses the first option, making sure to load the broadcast address into all active databases. Because of this, we can support per-port broadcast flooding by (1) making sure to only set the subset of ports that have it enabled whenever joining a new bridge or VLAN, and (2) by updating all active databases whenever the setting is changed on a port. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tobias Waldekranz authored
Allow a user to control automatic learning per port. Many chips have an explicit "LearningDisable"-bit that can be used for this, but we opt for setting/clearing the PAV instead, as it works on all devices at least as far back as 6083. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tobias Waldekranz authored
In accordance with the comment in dsa_port_bridge_leave, standalone ports shall be configured to flood all types of traffic. This change aligns the mv88e6xxx driver with that policy. Previously a standalone port would initially not egress any unknown traffic, but after joining and then leaving a bridge, it would. This does not matter that much since we only ever send FROM_CPUs on standalone ports, but it seems prudent to make sure that the initial values match those that are applied after a bridging/unbridging cycle. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tobias Waldekranz authored
Use the conventional declaration style of a MAC address in the kernel (u8 addr[ETH_ALEN]) for the broadcast address, then set it using the existing helper. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tobias Waldekranz authored
The hardware has a somewhat quirky protocol for reading out the VTU entry for a particular VID. But there is no reason why we cannot create a better API for ourselves in the driver. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-