- 12 Feb, 2021 22 commits
-
-
Johannes Berg authored
These were missed earlier, add the necessary documentation and, while at it, clarify it. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20210212105023.895c3389f063.I46dea3bfc64385bc6f600c50d294007510994f8f@changeidSigned-off-by:
-
Ben Greear authored
Allow user to disable HE mode, similar to how VHT and HT can be disabled. Useful for testing. Signed-off-by:
Ben Greear <greearb@candelatech.com> Link: https://lore.kernel.org/r/20210204144610.25971-1-greearb@candelatech.comSigned-off-by:
-
Philipp Borgers authored
This patch adds support for STBC encoding to the radiotap tx parse function. Prior to this change adding the STBC flag to the radiotap header did not encode frames with STBC. Signed-off-by:
Philipp Borgers <borgers@mi.fu-berlin.de> Link: https://lore.kernel.org/r/20210125150744.83065-1-borgers@mi.fu-berlin.de [use u8_get_bits/u32_encode_bits instead of manually shifting] Signed-off-by:
-
Felix Fietkau authored
This was added to mitigate the effects of too much sampling on devices that use a static global fallback table instead of configurable multi-rate retry. Now that the sampling algorithm is improved, this code path no longer performs any better than the standard probing on affected devices. Signed-off-by:
Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20210127055735.78599-6-nbd@nbd.nameSigned-off-by:
-
Felix Fietkau authored
This makes it easier to see what rates are going to be tested next Signed-off-by:
-
Felix Fietkau authored
The biggest flaw in current minstrel_ht is the fact that it needs way too many probing packets to be able to quickly find the best rate. Depending on the wifi hardware and operating mode, this can significantly reduce throughput when not operating at the highest available data rate. In order to be able to significantly reduce the amount of rate sampling, we need a much smarter selection of probing rates. The new approach introduced by this patch maintains a limited set of available rates to be tested during a statistics window. They are split into distinct categories: - MINSTREL_SAMPLE_TYPE_INC - incremental rate upgrade: Pick the next rate group and find the first rate that is faster than the current max. throughput rate - MINSTREL_SAMPLE_TYPE_JUMP - random testing of higher rates: Pick a random rate from the next group that is faster than the current max throughput rate. This allows faster adaptation when the link changes significantly - MINSTREL_SAMPLE_TYPE_SLOW - test a rate between max_prob, max_tp2 and max_tp in order to reduce the gap between them In order to prioritize sampling, every 6 attempts are split into 3x INC, 2x JUMP, 1x SLOW. Available rates are checked and refilled on every stats window update. With this approach, we finally get a very small delta in throughput when comparing setting the optimal data rate as a fixed rate vs normal rate control operation. Signed-off-by:
-
Felix Fietkau authored
In order to more gracefully be able to fall back to lower rates without too much throughput fluctuations, initialize all untested rates below tested ones to the maximum probabilty of higher rates. Usually this leads to untested lower rates getting initialized with a probability value of 100%, making them better candidates for fallback without having to rely on random probing Signed-off-by:
-
Felix Fietkau authored
Keep the update in one place and prepare for further rework Signed-off-by:
-
Felix Fietkau authored
Get rid of a lot of divisions and modulo operations Reduces code size and improves performance Signed-off-by:
-
Luca Coelho authored
Sparse started warning on this function because we can potentially return an uninitialized value. The reason is that if the caller passes a min_bw value that is higher then the last value in bws[], we will not go into the loop and reg_rule will remain initialized. This cannot happen because the only caller of this function uses either 1 or 20 in min_bw, but the function will be more robust if we pre-initialize the value. Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210204154439.6c884ea7281c.I257278d03b0c1ae0aa6631672cfa48f1a95d5996@changeidSigned-off-by:
-
Colin Ian King authored
The multiplication of the u32 variables tx_time and estimated_retx is performed using a 32 bit multiplication and the result is stored in a u64 result. This has a potential u32 overflow issue, so avoid this by casting tx_time to a u64 to force a 64 bit multiply. Addresses-Coverity: ("Unintentional integer overflow") Fixes: 050ac52c ("mac80211: code for on-demand Hybrid Wireless Mesh Protocol") Signed-off-by:Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210205175352.208841-1-colin.king@canonical.comSigned-off-by:
-
Markus Theil authored
This patch unifies sending control port frames over nl80211 and AF_PACKET sockets a little more. Before this patch, EAPOL frames got QoS prioritization only when using AF_PACKET sockets. __ieee80211_select_queue only selects a QoS-enabled queue for control port frames, when the control port protocol is set correctly on the skb. For the AF_PACKET path this works, but the nl80211 path used ETH_P_802_3. Another check for injected frames in wme.c then prevented the QoS TID to be copied in the frame. In order to fix this, get rid of the frame injection marking for nl80211 ctrl port and set the correct ethernet protocol. Please note: An erlier version of this path tried to prevent frame aggregation for control port frames in order to speed up the initial connection setup a little. This seemed to cause issues on my older Intel dvm-based hardware, and was therefore removed again. Future commits which try to reintroduce this have to check carefully how hw behaves with aggregated and non-aggregated traffic for the same TID. My NIC: Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74 Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Markus Theil <markus.theil@tu-ilmenau.de> Link: https://lore.kernel.org/r/20210206115112.567881-1-markus.theil@tu-ilmenau.deSigned-off-by:
-
Matteo Croce authored
The ieee80211 class registers a callback which actually does nothing. Given that the callback is optional, and all its accesses are protected by a NULL check, remove it entirely. Signed-off-by:
Matteo Croce <mcroce@microsoft.com> Link: https://lore.kernel.org/r/20210208113356.4105-1-mcroce@linux.microsoft.comSigned-off-by:
-
Arjun Roy authored
Explicitly define reserved field and require it and any subsequent fields to be zero-valued for now. Additionally, limit the valid CMSG flags that tcp_zerocopy_receive accepts. Fixes: 7eeba170 ("tcp: Add receive timestamp support for receive zerocopy.") Signed-off-by:
Arjun Roy <arjunroy@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Suggested-by:
David Ahern <dsahern@gmail.com> Suggested-by:
Leon Romanovsky <leon@kernel.org> Suggested-by:
Jakub Kicinski <kuba@kernel.org> Acked-by:
David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Cleaning up tx descriptors first increases the chance that rtl_rx() can allocate new skb's from the cache. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Cong Wang authored
dev_ifsioc_locked() is called with only RCU read lock, so when there is a parallel writer changing the mac address, it could get a partially updated mac address, as shown below: Thread 1 Thread 2 // eth_commit_mac_addr_change() memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN); // dev_ifsioc_locked() memcpy(ifr->ifr_hwaddr.sa_data, dev->dev_addr,...); Close this race condition by guarding them with a RW semaphore, like netdev_get_name(). We can not use seqlock here as it does not allow blocking. The writers already take RTNL anyway, so this does not affect the slow path. To avoid bothering existing dev_set_mac_address() callers in drivers, introduce a new wrapper just for user-facing callers on ioctl and rtnetlink paths. Note, bonding also changes slave mac addresses but that requires a separate patch due to the complexity of bonding code. Fixes: 3710becf ("net: RCU locking for simple ioctl()") Reported-by:
"Gong, Sishuai" <sishuai@purdue.edu> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Cong Wang <cong.wang@bytedance.com> Signed-off-by:
-
Stefan Chulski authored
The condition should be skipped if CPU ID equal to nthreads. The patch doesn't fix any actual issue since nthreads = min_t(unsigned int, num_present_cpus(), MVPP2_MAX_THREADS). On all current Armada platforms, the number of CPU's is less than MVPP2_MAX_THREADS. Fixes: e531f767 ("net: mvpp2: handle cases where more CPUs are available than s/w threads") Reported-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Stefan Chulski <stefanc@marvell.com> Reviewed-by:
-
David S. Miller authored
Vignesh Raghavendra says: ==================== net: ti: am65-cpsw-nuss: Add switchdev driver This series adds switchdev support for AM65 CPSW NUSS driver to support multi port CPSW present on J721e and AM64 SoCs. It adds devlink hook to switch b/w switch mode and multi mac mode. v2: Rebased on latest net-next Update patch 1/4 with rationale for using devlink ====================
-
Vignesh Raghavendra authored
J721e, J7200 and AM64 have multi port switches which can work in multi mac mode and in switch mode. Add documentation explaining how to use different modes. Borrowed from: Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by:
-
Vignesh Raghavendra authored
J721e, J7200 and AM64 have multi port switches which can work in multi mac mode and in switch mode. Add support for configuring this HW in switch mode using devlink and switchdev notifiers. Support is similar to existing CPSW switchdev implementation of TI's 32 bit platform like AM33/AM43/AM57. To enable switch mode: devlink dev param set platform/8000000.ethernet name switch_mode value true cmode runtime All configuration is implemented via switchdev API and notifiers. Supported: - SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS - SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS - SWITCHDEV_ATTR_ID_PORT_STP_STATE - SWITCHDEV_OBJ_ID_PORT_VLAN - SWITCHDEV_OBJ_ID_PORT_MDB - SWITCHDEV_OBJ_ID_HOST_MDB Hence AM65 CPSW switchdev driver supports: - FDB offloading - MDB offloading - VLAN filtering and offloading - STP Signed-off-by: -
Vignesh Raghavendra authored
Register netdevice notifiers in order to receive notification when individual MAC ports are added to the HW bridge. Signed-off-by:
-
Vignesh Raghavendra authored
AM65 NUSS ethernet switch on K3 devices can be configured to work either in independent mac mode where each port acts as independent network interface (multi mac) or switch mode. Add devlink hooks to provide a way to switch b/w these modes. Rationale to use devlink instead of defaulting to bridge mode is that SoC use cases require to support multiple independent MAC ports with no switching so that users can use software bridges with multi-mac configuration (e.g: to support LAG, HSR/PRP, etc). Also, switching between multi mac and switch mode requires significant Port and ALE reconfiguration, therefore is easier to be made as part of mode change devlink hooks. It also allows to keep user interface similar to what was implemented for the previous generation of TI CPSW IP (on AM33/AM43/AM57 SoCs). Signed-off-by:
-
- 11 Feb, 2021 18 commits
-
-
David S. Miller authored
Rafał Miłecki says: ==================== bcm4908_enet: post-review fixes V2 of my BCM4908 Ethernet patchset was applied to the net-next.git and it was later that is received some extra reviews. I'm sending patches that handle pointed out issues. David: earler I missed that V2 was applied and I sent V3 and V4 of my inital patchset. Sorry for that. I think it's the best to ignore V3 and V4 I sent and proceed with this fixes patchset instead. ==================== Signed-off-by: -
Rafał Miłecki authored
Use le32_to_cpu() for reading __le32 struct field filled by hw. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Rafał Miłecki authored
Use ETH_FCS_LEN instead of magic value and drop incorrect + 2 Signed-off-by:
-
Rafał Miłecki authored
1. Fix "ensable" typo noticed by Andrew 2. Fix chipset name in the struct net_device_ops variable Suggested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Rafał Miłecki authored
It seems preferred to let compiler optimize code if applicable. While at it drop unused enet_umac_maskset(). Suggested-by:
-
Rafał Miłecki authored
dma_alloc_coherent takes care of zeroing allocated memory Suggested-by:
-
Rafał Miłecki authored
compatible string was updated to match normal naming convention so update driver as well Signed-off-by:
-
Rafał Miłecki authored
It should be /included/ by every Ethernet controller binding. It adds support for various generic properties. Suggested-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Rafał Miłecki authored
Rob pointed out that a normal convention is "brcm,bcm4908-enet" so update whole binding to match it. Suggested-by:
-
git://git.kernel.org/pub/scm/linux/kernDavid S. Miller authored
el/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2021-02-11 Here's the main bluetooth-next pull request for 5.12: - Add support for advertising monitor offliading using Microsoft vendor extensions - Add firmware download support for MediaTek MT7921U USB devices - Suspend-related fixes for Qualcomm devices - Add support for Intel GarfieldPeak controller - Various other smaller fixes & cleanups Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by: -
David S. Miller authored
Geetha sowjanya says: ==================== Add Marvell CN10K support The current admin function (AF) driver and the netdev driver supports OcteonTx2 silicon variants. The same OcteonTx2's Resource Virtualization Unit (RVU) is carried forward to the next-gen silicon ie OcteonTx3, with some changes and feature enhancements. This patch set adds support for OcteonTx3 (CN10K) silicon and gets the drivers to the same level as OcteonTx2. No new OcteonTx3 specific features are added. Changes cover below HW level differences - PCIe BAR address changes wrt shared mailbox memory region - Receive buffer freeing to HW - Transmit packet's descriptor submission to HW - Programmable HW interface identifiers (channels) - Increased MTU support - A Serdes MAC block (RPM) configuration v5-v6 Rebased on top of latest net-next branch. v4-v5 Fixed sparse warnings. v3-v4 Fixed compiler warnings. v2-v3 Reposting as a single thread. Rebased on top latest net-next branch. v1-v2 Fixed check-patch reported issues. ==================== Signed-off-by: -
Hariprasad Kelam authored
MAC on CN10K silicon support loopback for selftest or debug purposes. This patch does necessary configuration to loopback packets upon receiving request from LMAC mapped RVU PF's netdev via mailbox. Also MAC (CGX) on OcteonTx2 silicon variants and MAC (RPM) on OcteonTx3 CN10K are different and loopback needs to be configured differently. Upper layer interface between RVU AF and PF netdev is kept same. Based on silicon variant appropriate fn() pointer is called to config the MAC. Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Signed-off-by:
Geetha sowjanya <gakula@marvell.com> Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> Reported-by:
-
Hariprasad Kelam authored
RPM supports below list of counters as an extension to existing counters * class based flow control pause frames * vlan/jabber/fragmented packets * fcs/alignment/oversized error packets This patch adds support to display supported RPM counters via debugfs and define new mbox rpm_stats to read all support counters. Signed-off-by:
Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com> Signed-off-by:
-
Rakesh Babu authored
Flow control configuration is different for CGX(Octeontx2) and RPM(CN10K) functional blocks. This patch adds the necessary changes for RPM to support 802.3 pause frames configuration on cn10k platforms. Signed-off-by:
Rakesh Babu <rsaladi2@marvell.com> Signed-off-by:
-
Hariprasad Kelam authored
CN10K supports max MTU of 16K on LMAC links and 64k on LBK links and Octeontx2 silicon supports 9K mtu on both links. Get the same from nix_get_hw_info mbox message in netdev probe. This patch also calculates receive buffer size required based on the MTU set. Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
-
Hariprasad Kelam authored
OcteonTx3 CN10K silicon supports bigger MTU when compared to 9216 MTU supported by OcteonTx2 silicon variants. Lookback interface supports upto 64K and RPM LMAC interfaces support upto 16K. This patch does the necessary configuration and adds support for PF/VF drivers to retrieve max packet size supported via mbox This patch also configures tx link credit by considering supported fifo size and max packet length for Octeontx3 silicon. This patch also removes platform specific name from the driver name. Signed-off-by:
-
Subbaraya Sundeep authored
NIX uses unique channel numbers to identify the packet sources/sinks like CGX,LBK and SDP. The channel numbers assigned to each block are hardwired in CN9xxx silicon. The fixed channel numbers in CN9xxx are: 0x0 | a << 8 | b - LBK(0..3)_CH(0..63) 0x0 | a << 8 - Reserved 0x700 | a - SDP_CH(0..255) 0x800 | a << 8 | b << 4 | c - CGX(0..7)_LMAC(0..3)_CH(0..15) All the channels in the above fixed enumerator(with maximum number of blocks) are not required since some chips have less number of blocks. For CN10K silicon the channel numbers need to be programmed by software in each block with the base channel number and range of channels. This patch calculates and assigns the channel numbers to efficiently distribute the channel number range(0-4095) among all the blocks. The assignment is made based on the actual number of blocks present and also contiguously leaving no holes. The channel numbers remaining after the math are used as new CPT replay channels present in CN10K. Also since channel numbers are not fixed the transmit channel link number needed by AF consumers is calculated by AF and sent along with nix_lf_alloc mailbox response. Signed-off-by:
-
Hariprasad Kelam authored
OcteonTx2's next gen platform the CN10K has RPM MAC which has a different serdes when compared to CGX MAC. Though the underlying HW is different, the CSR interface has been designed largely inline with CGX MAC, with few exceptions though. So we are using the same CGX driver for RPM MAC as well and will have a different set of APIs for RPM where ever necessary. This patch adds initial support for CN10K's RPM MAC i.e. the driver registration, communication with firmware etc. For communication with firmware, RPM provides a different IRQ when compared to CGX. The CGX and RPM blocks support different features. Currently few features like ptp, flowcontrol and higig are not supported by RPM. This patch adds new mailbox message "CGX_FEATURES_GET" to get the list of features supported by underlying MAC. RPM has different implementations for RX/TX stats. Unlike CGX, bar offset of stat registers are different. This patch adds support to access the same and dump the values in debugfs. Signed-off-by:
-
