- 22 Jun, 2021 4 commits
-
-
caihuoqing authored
remove "default n" and "No" is default Signed-off-by:
caihuoqing <caihuoqing@baidu.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Colin Ian King authored
There is a spelling mistake in a mlx5_core_err error message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Nathan Chancellor authored
When CONFIG_CPUMASK_OFFSTACK is unset, cpumask_var_t is not a pointer but a single element array, meaning its address in a structure cannot be NULL as long as it is not the first element, which it is not. This results in a clang warning: drivers/net/ethernet/mellanox/mlx5/core/eq.c:715:14: warning: address of array 'param->affinity' will always evaluate to 'true' [-Wpointer-bool-conversion] if (!param->affinity) ~~~~~~~~^~~~~~~~ 1 warning generated. The helper cpumask_available was added in commit f7e30f01 ("cpumask: Add helper cpumask_available()") to handle situations like this so use it to keep the meaning of the code the same while resolving the warning. Fixes: e4e3f24b ("net/mlx5: Provide cpumask at EQ creation phase") Link: https://github.com/ClangBuiltLinux/linux/issues/1400Signed-off-by:Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
Jiapeng Chong authored
The error code is missing in this code scenario, add the error code '-ENOMEM' to the return value 'err'. Eliminate the follow smatch warning: drivers/net/ethernet/mellanox/mlx5/core/fs_core.c:2973 mlx5_init_fs() warn: missing error code 'err'. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Fixes: 4a98544d ("net/mlx5: Move chains ft pool to be used by all firmware steering"). Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
- 21 Jun, 2021 36 commits
-
-
Kees Cook authored
Since these strings are expected to be NUL-terminated and the buffers are exactly sized (in vnic_client_data_len()) with no padding, strncpy() can be safely replaced with strscpy() here, as strncpy() on NUL-terminated string is considered deprecated[1]. This has the side-effect of silencing a -Warray-bounds warning due to the compiler being confused about the vlcd incrementing: In file included from ./include/linux/string.h:253, from ./include/linux/bitmap.h:10, from ./include/linux/cpumask.h:12, from ./include/linux/mm_types_task.h:14, from ./include/linux/mm_types.h:5, from ./include/linux/buildid.h:5, from ./include/linux/module.h:14, from drivers/net/ethernet/ibm/ibmvnic.c:35: In function '__fortify_strncpy', inlined from 'vnic_add_client_data' at drivers/net/ethernet/ibm/ibmvnic.c:3919:2: ./include/linux/fortify-string.h:39:30: warning: '__builtin_strncpy' offset 12 from the object at 'v lcd' is out of the bounds of referenced subobject 'name' with type 'char[]' at offset 12 [-Warray-bo unds] 39 | #define __underlying_strncpy __builtin_strncpy | ^ ./include/linux/fortify-string.h:51:9: note: in expansion of macro '__underlying_strncpy' 51 | return __underlying_strncpy(p, q, size); | ^~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/ibm/ibmvnic.c: In function 'vnic_add_client_data': drivers/net/ethernet/ibm/ibmvnic.c:3883:7: note: subobject 'name' declared here 3883 | char name[]; | ^~~~ [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings Cc: Dany Madden <drt@linux.ibm.com> Cc: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Cc: Thomas Falcon <tlfalcon@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:Kees Cook <keescook@chromium.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Guillaume Nault authored
Similar to commit 3b707c30 ("net: dev_is_mac_header_xmit() true for ARPHRD_RAWIP"), add ARPHRD_IP6GRE to dev_is_mac_header_xmit(), to make ip6gre compatible with act_mirred and __bpf_redirect(). Signed-off-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
-
Boris Sukholitko authored
This reverts commit 0dca2c74. The commit in question breaks hardware offload of flower filters. Quoting Vladimir Oltean <olteanv@gmail.com>: fl_hw_replace_filter() and fl_reoffload() create a struct flow_cls_offload with a rule->match.mask member derived from the mask of the software classifier: &f->mask->key - that same mask that is used for initializing the flow dissector keys, and the one from which Boris removed the basic.n_proto member because it was bothering him. Reported-by:
Vadym Kochan <vadym.kochan@plvision.eu> Signed-off-by:
Boris Sukholitko <boris.sukholitko@broadcom.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Esben Haabendal authored
Fixes: f6396341 ("net: ll_temac: Avoid ndo_start_xmit returning NETDEV_TX_BUSY") Signed-off-by:
Esben Haabendal <esben@geanix.com> Signed-off-by:
-
Yejune Deng authored
Modify the pr_info content from int to char * in sock_register() and sock_unregister(), this looks more readable. Fixed build error in ARCH=sparc64. Signed-off-by:
Yejune Deng <yejune.deng@gmail.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
David S. Miller authored
Zhou Yanjie says: ==================== Fix for Ingenic MAC support. 1.Remove the unexpected "snps,dwmac" item in the example. ==================== Signed-off-by: -
周琰杰 (Zhou Yanjie) authored
Remove the unexpected "snps,dwmac" item in the example. Fixes: 3b840106 ("dt-bindings: dwmac: Add bindings for new Ingenic SoCs.") Signed-off-by:
周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Signed-off-by:
-
Christophe JAILLET authored
If this 'kzalloc()' fails we must free some resources as in all the other error handling paths of this function. Fixes: 2e2deee7 ("net: hns3: add the RAS compatibility adaptation solution") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Jiaran Zhang <zhangjiaran@huawei.com> Signed-off-by:
-
David S. Miller authored
Joakim Zhang says: ==================== net: fec: fix TX bandwidth fluctuations This patch set intends to fix TX bandwidth fluctuations, any feedback would be appreciated. --- ChangeLogs: V1: remove RFC tag, RFC discussions please turn to below: https://lore.kernel.org/lkml/YK0Ce5YxR2WYbrAo@lunn.ch/T/ V2: change functions to be static in this patch set. And add the t-b tag. V3: fix sparse warining: ntohs()->htons() ==================== Signed-off-by:
-
Fugang Duan authored
As we know that AVB is enabled by default, and the ENET IP design is queue 0 for best effort, queue 1&2 for AVB Class A&B. Bandwidth of each queue 1&2 set in driver is 50%, TX bandwidth fluctuated when selecting tx queues randomly with FEC_QUIRK_HAS_AVB quirk available. This patch adds ndo_select_queue callback to select queues for transmitting to fix this issue. It will always return queue 0 if this is not a vlan packet, and return queue 1 or 2 based on priority of vlan packet. You may complain that in fact we only use single queue for trasmitting if we are not targeted to VLAN. Yes, but seems we have no choice, since AVB is enabled when the driver probed, we can't switch this feature dynamicly. After compare multiple queues to single queue, TX throughput almost no improvement. One way we can implemet is to configure the driver to multiple queues with Round-robin scheme by default. Then add ndo_setup_tc callback to enable/disable AVB feature for users. Unfortunately, ENET AVB IP seems not follow the standard 802.1Qav spec. We only can program DMAnCFG[IDLE_SLOPE] field to calculate bandwidth fraction. And idle slope is restricted to certain valus (a total of 19). It's far away from CBS QDisc implemented in Linux TC framework. If you strongly suggest to do this, I think we only can support limited numbers of bandwidth and reject others, but it's really urgly and wried. With this patch, VLAN tagged packets route to queue 0/1/2 based on vlan priority; VLAN untagged packets route to queue 0. Tested-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Reported-by:
Fugang Duan <fugang.duan@nxp.com> Signed-off-by:
Joakim Zhang <qiangqing.zhang@nxp.com> Reported-by:
-
Joakim Zhang authored
Frieder Schrempf reported a TX throuthput issue [1], it happens quite often that the measured bandwidth in TX direction drops from its expected/nominal value to something like ~50% (for 100M) or ~67% (for 1G) connections. [1] https://lore.kernel.org/linux-arm-kernel/421cc86c-b66f-b372-32f7-21e59f9a98bc@kontron.de/ The issue becomes clear after digging into it, Net core would select queues when transmitting packets. Since FEC have not impletemented ndo_select_queue callback yet, so it will call netdev_pick_tx to select queues randomly. For i.MX6SX ENET IP with AVB support, driver default enables this feature. According to the setting of QOS/RCMRn/DMAnCFG registers, AVB configured to Credit-based scheme, 50% bandwidth of each queue 1&2. With below tests let me think more: 1) With FEC_QUIRK_HAS_AVB quirk, can reproduce TX bandwidth fluctuations issue. 2) Without FEC_QUIRK_HAS_AVB quirk, can't reproduce TX bandwidth fluctuations issue. The related difference with or w/o FEC_QUIRK_HAS_AVB quirk is that, whether we program FTYPE field of TxBD or not. As I describe above, AVB feature is enabled by default. With FEC_QUIRK_HAS_AVB quirk, frames in queue 0 marked as non-AVB, and frames in queue 1&2 marked as AVB Class A&B. It's unreasonable if frames in queue 1&2 are not required to be time-sensitive. So when Net core select tx queues ramdomly, Credit-based scheme would work and lead to TX bandwidth fluctuated. On the other hand, w/o FEC_QUIRK_HAS_AVB quirk, frames in queue 1&2 are all marked as non-AVB, so Credit-based scheme would not work. Till now, how can we fix this TX throughput issue? Yes, please remove FEC_QUIRK_HAS_AVB quirk if you suffer it from time-nonsensitive networking. However, this quirk is used to indicate i.MX6SX, other setting depends on it. So this patch adds a new quirk FEC_QUIRK_HAS_MULTI_QUEUES to represent i.MX6SX, it is safe for us remove FEC_QUIRK_HAS_AVB quirk now. FEC_QUIRK_HAS_AVB quirk is set by default in the driver, and users may not know much about driver details, they would waste effort to find the root cause, that is not we want. The following patch is a implementation to fix it and users don't need to modify the driver. Tested-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Improvement for DSA cross-chip setups This series improves some aspects in multi-switch DSA tree topologies: - better device tree validation - better handling of MTU changes - better handling of multicast addresses - removal of some unused code ==================== Signed-off-by: -
Vladimir Oltean authored
With MRP hardware assist being supported only by the ocelot switch family, which by design does not support cross-chip bridging, the current match functions are at best a guess and have not been confirmed in any way to do anything relevant in a multi-switch topology. Drop the code and make the notifiers match only on the targeted switch port. Cc: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
dsa_slave_change_mtu() calls dsa_port_mtu_change() twice: - it sends a cross-chip notifier with the MTU of the CPU port which is used to update the DSA links. - it sends one targeted MTU notifier which is supposed to only match the user port on which we are changing the MTU. The "propagate_upstream" variable is used here to bypass the cross-chip notifier system from switch.c But due to a mistake, the second, targeted notifier matches not only on the user port, but also on the DSA link which is a member of the same switch, if that exists. And because the DSA links of the entire dst were programmed in a previous round to the largest_mtu via a "propagate_upstream == true" notification, then the dsa_port_mtu_change(propagate_upstream == false) call that is immediately upcoming will break the MTU on the one DSA link which is chip-wise local to the dp whose MTU is changing right now. Example given this daisy chain topology: sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ cpu ] [ user ] [ user ] [ dsa ] [ user ] [ x ] [ ] [ ] [ x ] [ ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] [ ] [ ] [ ] [ ] [ x ] ip link set sw0p1 mtu 9000 ip link set sw1p1 mtu 9000 # at this stage, sw0p1 and sw1p1 can talk # to one another using jumbo frames ip link set sw0p2 mtu 1500 # this programs the sw0p3 DSA link first to # the largest_mtu of 9000, then reprograms it to # 1500 with the "propagate_upstream == false" # notifier, breaking communication between # sw0p1 and sw1p1 To escape from this situation, make the targeted match really match on a single port - the user port, and rename the "propagate_upstream" variable to "targeted_match" to clarify the intention and avoid future issues. Signed-off-by: -
Vladimir Oltean authored
If we have a cross-chip topology like this: sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ cpu ] [ user ] [ user ] [ dsa ] [ user ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] and we issue the following commands: 1. ip link set sw0p1 mtu 1700 2. ip link set sw1p1 mtu 1600 we notice the following happening: Command 1. emits a non-targeted MTU notifier for the CPU port (sw0p0) with the largest_mtu calculated across switch 0, of 1700. This matches sw0p0, sw0p3 and sw1p4 (all CPU ports and DSA links). Then, it emits a targeted MTU notifier for the user port (sw0p1), again with MTU 1700 (this doesn't matter). Command 2. emits a non-targeted MTU notifier for the CPU port (sw0p0) with the largest_mtu calculated across switch 1, of 1600. This matches the same group of ports as above, and decreases the MTU for the CPU port and the DSA links from 1700 to 1600. As a result, the sw0p1 user port can no longer communicate with its CPU port at MTU 1700. To address this, we should calculate the largest_mtu across all switches that may share a CPU port, and only emit MTU notifiers with that value. Signed-off-by: -
Vladimir Oltean authored
Currently, the notifier for adding a multicast MAC address matches on the targeted port and on all DSA links in the system, be they upstream or downstream links. This leads to a considerable amount of useless traffic. Consider this daisy chain topology, and a MDB add notifier emitted on sw0p0. It matches on sw0p0, sw0p3, sw1p3 and sw2p4. sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ user ] [ user ] [ user ] [ dsa ] [ cpu ] [ x ] [ ] [ ] [ x ] [ ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] [ ] [ ] [ ] [ x ] [ x ] | +---------+ | sw2p0 sw2p1 sw2p2 sw2p3 sw2p4 [ user ] [ user ] [ user ] [ user ] [ dsa ] [ ] [ ] [ ] [ ] [ x ] But switch 0 has no reason to send the multicast traffic for that MAC address on sw0p3, which is how it reaches switches 1 and 2. Those switches don't expect, according to the user configuration, to receive this multicast address from switch 1, and they will drop it anyway, because the only valid destination is the port they received it on. They only need to configure themselves to deliver that multicast address _towards_ switch 1, where the MDB entry is installed. Similarly, switch 1 should not send this multicast traffic towards sw1p3, because that is how it reaches switch 2. With this change, the heat map for this MDB notifier changes as follows: sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ user ] [ user ] [ user ] [ dsa ] [ cpu ] [ x ] [ ] [ ] [ ] [ ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] [ ] [ ] [ ] [ ] [ x ] | +---------+ | sw2p0 sw2p1 sw2p2 sw2p3 sw2p4 [ user ] [ user ] [ user ] [ user ] [ dsa ] [ ] [ ] [ ] [ ] [ x ] Now the mdb notifier behaves the same as the fdb notifier. Signed-off-by: -
Vladimir Oltean authored
The difference between dsa_is_user_port and dsa_port_is_user is that the former needs to look up the list of ports of the DSA switch tree in order to find the struct dsa_port, while the latter directly receives it as an argument. dsa_is_user_port is already in widespread use and has its place, so there isn't any chance of converting all callers to a single form. But being able to do: dsa_port_is_user(dp) instead of dsa_is_user_port(dp->ds, dp->index) is much more efficient too, especially when the "dp" comes from an iterator over the DSA switch tree - this reduces the complexity from quadratic to linear. Move these helpers from dsa2.c to include/net/dsa.h so that others can use them too. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Vladimir Oltean authored
The cross-chip notifiers work by comparing each ds->index against the info->sw_index value from the notifier. The ds->index is retrieved from the device tree dsa,member property. If a single tree cross-chip topology does not declare unique switch IDs, this will result in hard-to-debug issues/voodoo effects such as the cross-chip notifier for one switch port also matching the port with the same number from another switch. Check in dsa_switch_parse_member_of() whether the DSA switch tree contains a DSA switch with the index we're preparing to add, before actually adding it. Signed-off-by:
-
Peng Li authored
According to the chackpatch.pl, no space before tabs. Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
-
Peng Li authored
According to the chackpatch.pl, comparison to NULL could be written "!card". Signed-off-by:
-
Peng Li authored
This patch fixes the checkpatch error about missing a blank line after declarations. Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Add support for module EEPROM read by page Add support for ethtool_ops::get_module_eeprom_by_page() operation. Patch #1 adds necessary field in device register. Patch #2 documents possible MCIA status values so that more meaningful error messages could be returned to user space via extack. Patch #3 adds the actual implementation. =================== Signed-off-by: -
Ido Schimmel authored
Add support for ethtool_ops::get_module_eeprom_by_page() which allows user space to read transceiver module EEPROM based on passed parameters. The I2C address is not validated in order to avoid module-specific code. In case of wrong address, error will be returned from device's firmware. Tested by comparing output with legacy method (ioctl) output. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Tested-by:
Vadim Pasternak <vadimp@nvidia.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Ido Schimmel authored
Will be used to emit meaningful messages to user space via extack in a subsequent patch. Signed-off-by:
-
Ido Schimmel authored
Add bank number to MCIA (Management Cable Info Access) register in order to allow access to banked pages on EEPROMs using CMIS (Common Management Interface Specification) memory map. Signed-off-by:
-
David S. Miller authored
Alex Elder says: ==================== net: ipa: add support for IPA v3.1 This series adds support for IPA v3.1, used by the Qualcomm Snapdragon 835 (MSM8998). The first patch adds "qcom,msm8998-ipa" to the DT binding. The next four patches add code to ensure correct operation on IPA v3.1: - Avoid touching unsupported inter-EE interrupt mask registers - Set the proper flags in the clock configuration register - Work around the lack of an IPA FLAVOR_0 register - Work around the lack of a GSI PARAM_2 register The last patch defines configuration data for this version of IPA. Many thanks are due to AngeloGioacchino Del Regno and Jami Kettunen, both associated with SoMainline. Angelo first posted code to implement most of what was required for this, and Jami has been helpful testing these changes on his hardware. ==================== Signed-off-by: -
Alex Elder authored
Add support for the MSM8998 SoC, which includes IPA version 3.1. Originally proposed by AngeloGioacchino Del Regno. Link: https://lore.kernel.org/netdev/20210211175015.200772-6-angelogioacchino.delregno@somainline.orgSigned-off-by:
Alex Elder <elder@linaro.org> Acked-by: AngeloGioacchino Del Regno Signed-off-by:
-
Alex Elder authored
Prior to IPA v3.5.1, there is no HW_PARAM_2 GSI register, which we use to determine the number of channels and endpoints per execution environment. In that case, we will just assume the number supported is the maximum supported by the driver. Introduce gsi_ring_setup() to encapsulate the code that determines the number of channels and endpoints. Update GSI_EVT_RING_COUNT_MAX so it is big enough to handle any available channel for all supported hardware (IPA v4.9 can have 23 channels and 24 event rings). Signed-off-by:
-
Alex Elder authored
The FLAVOR_0 version first appears in IPA v3.5, so avoid attempting to read it for versions prior to that. This register contains a concise definition of the number and direction of endpoints supported by the hardware, and without it we can't verify endpoint configuration in ipa_endpoint_config(). In this case, just indicate that any endpoint number is available for use. Originally proposed by AngeloGioacchino Del Regno. Link: https://lore.kernel.org/netdev/20210211175015.200772-3-angelogioacchino.delregno@somainline.orgSigned-off-by:
-
Alex Elder authored
For IPA v3.1, a workaround is needed to disable gating on a MISC clock. I have no further explanation, but this is what the downstream code (msm-4.4) does. This was suggested in a patch from AngeloGioacchino Del Regno. Link: https://lore.kernel.org/netdev/20210211175015.200772-2-angelogioacchino.delregno@somainline.orgSigned-off-by:
-
Alex Elder authored
The GSI inter-EE interrupts are not supported prior to IPA v3.5. Don't attempt to initialize them in gsi_irq_setup() for hardware that does not support them. Originally proposed by AngeloGioacchino Del Regno. Link: https://lore.kernel.org/netdev/20210211175015.200772-4-angelogioacchino.delregno@somainline.orgSigned-off-by:
-
Alex Elder authored
Add support for "qcom,msm8998-ipa", which uses IPA v3.1. Originally proposed by AngeloGioacchino Del Regno. Link: https://lore.kernel.org/linux-arm-msm/20210211175015.200772-8-angelogioacchino.delregno@somainline.orgSigned-off-by:
-
Al Viro authored
We only care about exclusive or of those, so pass that directly. Makes life simpler for callers as well... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
We can do that more or less safely, since the parent is held locked all along. Yes, somebody might observe the object via dcache, only to have it disappear afterwards, but there's really no good way to prevent that. It won't race with other bind(2) or attempts to move the sucker elsewhere, or put something else in its place - locked parent prevents that. Signed-off-by:
-
Al Viro authored
Final preparations for doing unlink on failure past the successful mknod. We can't hold ->bindlock over ->mknod() or ->unlink(), since either might do sb_start_write() (e.g. on overlayfs). However, we can do it while holding filesystem and VFS locks - doing kern_path_create() vfs_mknod() grab ->bindlock if u->addr had been set drop ->bindlock done_path_create return -EINVAL else assign the address to socket drop ->bindlock done_path_create return 0 would be deadlock-free. Here we massage unix_bind_bsd() to that form. We are still doing equivalent transformations. Next commit will *not* be an equivalent transformation - it will add a call of vfs_unlink() before done_path_create() in "alread bound" case. Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
