- 22 Feb, 2019 14 commits
-
-
Florian Fainelli authored
A missing break keyword should have been added after adding support for PRE_BRIDGE_FLAGS. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 93700458 ("rocker: Check Handle PORT_PRE_BRIDGE_FLAGS") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Huazhong Tan says: ==================== code optimizations & bugfixes for HNS3 driver This patchset includes bugfixes and code optimizations for the HNS3 ethernet controller driver. ==================== Signed-off-by: -
Huazhong Tan authored
According to the hardware's description, the driver should clear the command queue's registers when uloading VF driver. Otherwise, these existing value may lead the IMP get into a wrong state. Fixes: fedd0c15 ("net: hns3: Add HNS3 VF IMP(Integrated Management Proc) cmd interface") Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
-
Huazhong Tan authored
According to the hardware's description, the driver should clear the command queue's registers when uloading driver. Otherwise, these existing value may lead the IMP get into a wrong state. Also this patch adds hclge_cmd_uninit() to do the command queue uninitialization which includes clearing registers and freeing memory. Fixes: 68c0a5c7 ("net: hns3: Add HNS3 IMP(Integrated Mgmt Proc) Cmd Interface Support") Signed-off-by:
-
liuzhongzhu authored
Record the vlan tables that the VF sends to the chip. After the VF exception, the PF actively clears the VF to chip config. Signed-off-by:
liuzhongzhu <liuzhongzhu@huawei.com> Signed-off-by:
-
liuzhongzhu authored
Record the unicast and multicast tables that the VF sends to the chip. After the VF exception, the PF actively clears the VF to chip config. Signed-off-by:
-
Weihang Li authored
This patch modify print message of 6th bit of ppp mpf abnormal errors, there is a extra letter e in it. Signed-off-by:
Weihang Li <liweihang@hisilicon.com> Signed-off-by:
-
Weihang Li authored
These bits are enabled now and have been test. Signed-off-by:
-
Weihang Li authored
The 3rd and 4th of PPU(RCB) PF Abnormal is RAS errors instead of MSI-X like other bits. This patch adds process of handling and logging this two bits. Otherwise, this patch modifies print message of 28th and 29th bit of PPU MPF Abnormal errors, which keep same with other errors now. Fixes: f69b10b3 ("net: hns3: handle hw errors of PPU(RCB)") Signed-off-by:
-
Weihang Li authored
This patch add information of specific bit in log to be consistent with other type of errors, so that we can know which memory of ssu has occurred a ecc ras errors. Signed-off-by:
-
Jian Shen authored
In original codes, for copper port which doesn't connect to phy, it always returns -EOPNOTSUPP when query port information. This patch fixes it by return the port information of MAC. Fixes: 5f373b15 ("net: hns3: Fix speed/duplex information loss problem when executing ethtool ethx cmd of VF") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
-
Jian Shen authored
The link mode with bits has been up to more than 31 for some MAC and phy. Convert to using a linkmode bitmap, which can support all link modes. Signed-off-by:
-
Yonglong Liu authored
In hnae3_register_ae_dev(), ae_algo->ops is assigned to ae_dev->ops before check that ae_algo->ops is valid. And in hnae3_register_ae_algo(), missing check for ae_algo->ops. This patch fixes them. Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
-
Yonglong Liu authored
These functions are exported, add pointer checking at the beginning can make them more safe. Signed-off-by:
-
- 21 Feb, 2019 26 commits
-
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Support for shared buffers in Spectrum-2 Petr says: Spectrum-2 will be configured with a different set of pools than Spectrum-1, their sizes will be larger, and the individual quotas will be different as well. It is therefore necessary to make the shared buffer module aware of this dependence on chip type, and adjust the individual tables. In patch #1, introduce a structure for keeping per-chip immutable and default values. In patch #2, structures for keeping current values of SBPM and SBPR (pool configuration and port-pool quota) are allocated dynamically to support varying pool counts. In patches #3 to #7, uses of individual shared buffer configuration tables are migrated from global definitions to fields in struct mlxsw_sp_sb_vals, which was introduced above. Up until this point, the actual configuration is still the one suitable for Spectrum-1. In patch #8 Spectrum-2 configuration is added. In patch #9, port headroom configuration is changed to take into account current recommended value for a 100-Gbps port, and the split factor. In patch #10, requests for overlarge headroom are rejected. This avoids potential chip freeze should such overlarge requests be made. ==================== Signed-off-by: -
Petr Machata authored
cap_max_headroom_size holds maximum headroom size supported. Overstepping that limit might under certain conditions lead to ASIC freeze. Query and store the value, and add mlxsw_sp_sb_max_headroom_cells() for obtaining the stored value. In __mlxsw_sp_port_headroom_set(), reject requests where the total port buffer is larger than the advertised maximum. Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Petr Machata authored
The recommendation for headroom size for 100Gbps port and 100m cable is 101.6KB, reduced accordingly for split ports. The closest higher number evenly divisible by cell size for both Spectrum-1 and Spectrum-2, and such that the number of cells can be further divided by maximum split factor of 4, is 102528 bytes, or 25632 bytes per lane. Update mlxsw_sp_port_pb_init() to compute the headroom taking into account this recommended per-lane value and number of lanes actually dedicated to a given port. Signed-off-by:
-
Petr Machata authored
Customize the tables related to shared buffer configuration to match the current recommendation for Spectrum-2 systems. Signed-off-by:
-
Petr Machata authored
The SBMM register configures the shared buffer quota for MC packets according to Switch-Priority. The default configuration depends on the chip type. Therefore keep the table and length in struct mlxsw_sp_sb_vals. Redirect the references from the global definitions to the fields. Signed-off-by:
-
Petr Machata authored
The SBCM register configures shared buffer quota according to port-priority resp. port-TC. The default configuration depends on the chip type. Therefore keep the tables and their lengths in struct mlxsw_sp_sb_vals. Redirect the references from the global definitions to the fields. Signed-off-by:
-
Petr Machata authored
The SBPR register configures shared buffer pools. The default configuration depends on the chip type. Therefore keep it in struct mlxsw_sp_sb_vals. Redirect the one reference from the global array to the field. Because the pool descriptor ID is implicit in the ordering of array members, both this array and the pool descriptor array have the same length. Therefore reuse mlxsw_sp_sb.pool_dess_len for the purpose of determining the length of SBPR array. Drop the now useless MLXSW_SP_SB_PRS_LEN. Signed-off-by:
-
Petr Machata authored
The SBPM register can be used to configure quotas for packets ingressing from a certain pool to a certain port, and egressing from a certain pool to a certain port. The default configuration depends on the chip type. Therefore keep it in struct mlxsw_sp_sb_vals. Redirect the one reference from the global array to the field. Because the pool descriptor ID is implicit in the ordering of array members, both this array and the pool descriptor array have the same length. Therefore reuse mlxsw_sp_sb.pool_dess_len for the purpose of determining the length of SBPM array. Drop the now useless MLXSW_SP_SB_PMS_LEN. Signed-off-by:
-
Petr Machata authored
Keep the table of pool descriptors and its length in struct mlxsw_sp_sb_vals so that it can be specialized per chip type. Redirect all users from the global definitions to the mlxsw_sp_sb fields. Give mlxsw_sp_pool_count() an extra mlxsw_sp parameter so that it can access the descriptor table. Drop the now unnecessary MLXSW_SP_SB_POOL_DESS_LEN. Signed-off-by:
-
Petr Machata authored
Spectrum-2 will be configured with a different set of pools than Spectrum-1. The size of prs and pms buffers will therefore depend on the chip type of the device. Therefore, instead of reserving an array directly in a structure definition, allocate the buffer in mlxsw_sp_sb_port{,s}_init(). Signed-off-by: -
Petr Machata authored
Spectrum-2 will be configured with a different shared buffer configuration than Spectrum-1. Therefore introduce a structure for keeping the chip-specific default and immutable configuration. Configuration mutable in runtime will still be kept in struct mlxsw_sp_sb. Signed-off-by:
-
David S. Miller authored
Jose Abreu says: ==================== net: stmmac: Performance improvements in Multi-Queue Tested in XGMAC2 and GMAC5. ==================== Signed-off-by: -
Jose Abreu authored
TBU interrupt is a normal interrupt and can be used to trigger the cleaning of TX path. Lets check if it's active in DMA interrupt handler. While at it, refactor a little bit the function: - Don't check if RI is enabled because at function exit we will only clear the interrupts that are enabled so, no event will be missed. In my tests withe XGMAC2 this increased performance. Signed-off-by:
Jose Abreu <joabreu@synopsys.com> Cc: Joao Pinto <jpinto@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by:
-
Jose Abreu authored
TBU interrupt is a normal interrupt and can be used to trigger the cleaning of TX path. Lets check if it's active in DMA interrupt handler. While at it, refactor a little bit the function: - Don't check if RI is enabled because at function exit we will only clear the interrupts that are enabled so, no event will be missed. In my tests with GMAC5 this increased performance. Signed-off-by:
-
Jose Abreu authored
Commit 8fce3331 introduced the concept of NAPI per-channel and independent cleaning of TX path. This is currently breaking performance in some cases. The scenario happens when all packets are being received in Queue 0 but the TX is performed in Queue != 0. Fix this by using different NAPI instances per each TX and RX queue, as suggested by Florian. Changes from v2: - Only force restart transmission if there are pending packets Changes from v1: - Pass entire ring size to TX clean path (Florian) Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: Get rid of switchdev_port_attr_get() This patch series splits the removal of the switchdev_ops that was proposed a few times before and first tackles the easy part which is the removal of the single call to switchdev_port_attr_get() within the bridge code. As suggestd by Ido, this patch series adds a SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS which is used in the same context as the caller of switchdev_port_attr_set(), so not deferred, and then the operation is carried out in deferred context with setting a support bridge port flag. Follow-up patches will do the switchdev_ops removal after introducing the proper helpers for the switchdev blocking notifier to work across stacked devices (unlike the previous submissions). David this does depend on Russell's "[PATCH net-next v5 0/3] net: dsa: mv88e6xxx: fix IPv6". Changes in v3: - rebased against net-next/master after Russell's IPv6 changes to DSA - ignore prepare/commit phase for PRE_BRIDGE_FLAGS since we don't want to trigger the WARN() in net/switchdev/switchdev.c in the commit phase Changes in v2: - differentiate callers not supporting switchdev_port_attr_set() from the driver not being able to support specific bridge flags - pass "mask" instead of "flags" for the PRE_BRIDGE_FLAGS check - skip prepare phase for PRE_BRIDGE_FLAGS - corrected documentation a bit more - tested bridge_vlan_aware.sh with veth/VRF ==================== Signed-off-by: -
Florian Fainelli authored
With the bridge no longer calling switchdev_port_attr_get() to obtain the supported bridge port flags from a driver but instead trying to set the bridge port flags directly and relying on driver to reject unsupported configurations, we can effectively get rid of switchdev_port_attr_get() entirely since this was the only place where it was called. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Florian Fainelli authored
Now that we have converted the bridge code and the drivers to check for bridge port(s) flags at the time we try to set them, there is no need for a get() -> set() sequence anymore and SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT therefore becomes unused. Reviewed-by:
-
Florian Fainelli authored
Now that all switchdev drivers have been converted to check the SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS flags and report flags that they do not support accordingly, we can migrate the bridge code to try to set that attribute first, check the results and then do the actual setting. Signed-off-by:
-
Florian Fainelli authored
In preparation for getting rid of switchdev_port_attr_get(), have rocker check for the bridge flags being set through switchdev_port_attr_set() with the SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS attribute identifier. Signed-off-by:
-
Florian Fainelli authored
In preparation for removing SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT, add support for a function that processes the SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS and SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS attributes and returns not supported for any flag set, since DSA does not currently support toggling those bridge port attributes (yet). Signed-off-by:
-
Florian Fainelli authored
In preparation for removing SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT, handle the SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS attribute and check that the bridge port flags being configured are supported. Signed-off-by:
-
Florian Fainelli authored
In preparation for getting rid of switchdev_port_attr_get(), have mlxsw check for the bridge flags being set through switchdev_port_attr_set() when the SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS attribute identifier is used. Signed-off-by:
-
Florian Fainelli authored
In preparation for removing switchdev_port_attr_get(), introduce PORT_PRE_BRIDGE_FLAGS which will be called through switchdev_port_attr_set(), in the caller's context (possibly atomic) and which must be checked by the switchdev driver in order to return whether the operation is supported or not. This is entirely analoguous to how the BRIDGE_FLAGS_SUPPORT works, except it goes through a set() instead of get(). Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: dsa: mv88e6xxx: fix IPv6 We have had some emails in private over this issue, this is my current patch set rebased on top of net-next which provides working IPv6 (and probably other protocols as well) over mv88e6xxx DSA switches. The problem comes down to mv88e6xxx defaulting to not flood unknown unicast and multicast datagrams, as they would be by dumb switches, and as the Linux bridge code does by default. There is also the issue of IPv6 over a vlan that is transparent to the bridge; the multicast querier will not reach inside the vlan, and so the switch can not learn about multicast routing within the vlan. These flood settings can be disabled via the Linux bridge code if it's desired to make the switch behave more like a managed switch, eg, by enabling the multicast querier. However, the multicast querier defaults to being disabled which effectively means that by default, mv88e6xxx switches block all multicast traffic. This is at odds with the Linux bridge documentation, and the defaults that the Linux bridge code adopts. So, this patch set adds DSA support for Linux bridge flags, adds mv88e6xxx support for the unicast and multicast flooding flags, and lastly enables flooding of these frames by default to match the Linux bridge defaults. ==================== Signed-off-by: -
Russell King authored
Switches work by learning the MAC address for each attached station by monitoring traffic from each station. When a station sends a packet, the switch records which port the MAC address is connected to. With IPv4 networking, before communication commences with a neighbour, an ARP packet is broadcasted to all stations asking for the MAC address corresponding with the IPv4. The desired station responds with an ARP reply, and the ARP reply causes the switch to learn which port the station is connected to. With IPv6 networking, the situation is rather different. Rather than broadcasting ARP packets, a "neighbour solicitation" is multicasted rather than broadcasted. This multicast needs to reach the intended station in order for the neighbour to be discovered. Once a neighbour has been discovered, and entered into the sending stations neighbour cache, communication can restart at a point later without sending a new neighbour solicitation, even if the entry in the neighbour cache is marked as stale. This can be after the MAC address has expired from the forwarding cache of the DSA switch - when that occurs, there is a long pause in communication. Our DSA implementation for mv88e6xxx switches disables flooding of multicast and unicast frames for bridged ports. As per the above description, this is fine for IPv4 networking, since the broadcasted ARP queries will be sent to and received by all stations on the same network. However, this breaks IPv6 very badly - blocking neighbour solicitations and later causing connections to stall. The defaults that the Linux bridge code expect from bridges are for unknown unicast and unknown multicast frames to be flooded to all ports on the bridge, which is at odds to the defaults adopted by our DSA implementation for mv88e6xxx switches. This commit enables by default flooding of both unknown unicast and unknown multicast frames whenever a port is added to a bridge, and disables the flooding when a port leaves the bridge. This means that mv88e6xxx DSA switches now behave as per the bridge(8) man page, and IPv6 works flawlessly through such a switch. Reviewed-by:
Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
