- 11 May, 2020 13 commits
-
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Jakub Kicinski authored
Vladimir Oltean says: ==================== This series adds support for boards where DSA switches of multiple types are cascaded together. Actually this type of setup was brought up before on netdev, and it looks like utilizing disjoint trees is the way to go: https://lkml.org/lkml/2019/7/7/225 The trouble with disjoint trees (prior to this patch series) is that only bridging of ports within the same hardware switch can be offloaded. After scratching my head for a while, it looks like the easiest way to support hardware bridging between different DSA trees is to bridge their DSA masters and extend the crosschip bridging operations. I have given some thought to bridging the DSA masters with the slaves themselves, but given the hardware topology described in the commit message of patch 4/4, virtually any number (and combination) of bridges (forwarding domains) can be created on top of those 3x4-port front-panel switches. So it becomes a lot less obvious, when the front-panel ports are enslaved to more than 1 bridge, which bridge should the DSA masters be enslaved to. So the least awkward approach was to just create a completely separate bridge for the DSA masters, whose entire purpose is to permit hardware forwarding between the discrete switches beneath it. This is a direct resend of v3, which was deferred due to lack of review. In the meantime Florian has reviewed and tested some of them. v1 was submitted here: https://patchwork.ozlabs.org/project/netdev/cover/20200429161952.17769-1-olteanv@gmail.com/ v2 was submitted here: https://patchwork.ozlabs.org/project/netdev/cover/20200430202542.11797-1-olteanv@gmail.com/ v3 was submitted here: https://patchwork.ozlabs.org/project/netdev/cover/20200503221228.10928-1-olteanv@gmail.com/ ==================== Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Vladimir Oltean authored
sja1105 uses dsa_8021q for DSA tagging, a format which is VLAN at heart and which is compatible with cascading. A complete description of this tagging format is in net/dsa/tag_8021q.c, but a quick summary is that each external-facing port tags incoming frames with a unique pvid, and this special VLAN is transmitted as tagged towards the inside of the system, and as untagged towards the exterior. The tag encodes the switch id and the source port index. This means that cross-chip bridging for dsa_8021q only entails adding the dsa_8021q pvids of one switch to the RX filter of the other switches. Everything else falls naturally into place, as long as the bottom-end of ports (the leaves in the tree) is comprised exclusively of dsa_8021q-compatible (i.e. sja1105 switches). Otherwise, there would be a chance that a front-panel switch transmits a packet tagged with a dsa_8021q header, header which it wouldn't be able to remove, and which would hence "leak" out. The only use case I tested (due to lack of board availability) was when the sja1105 switches are part of disjoint trees (however, this doesn't change the fact that multiple sja1105 switches still need unique switch identifiers in such a system). But in principle, even "true" single-tree setups (with DSA links) should work just as fine, except for a small change which I can't test: dsa_towards_port should be used instead of dsa_upstream_port (I made the assumption that the routing port that any sja1105 should use towards its neighbours is the CPU port. That might not hold true in other setups). Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
Somewhat similar to dsa_tree_find, dsa_switch_find returns a dsa_switch structure pointer by searching for its tree index and switch index (the parameters from dsa,member). To be used, for example, by drivers who implement .crosschip_bridge_join and need a reference to the other switch indicated to by the tree_index and sw_index arguments. Signed-off-by:
-
Vladimir Oltean authored
One way of utilizing DSA is by cascading switches which do not all have compatible taggers. Consider the following real-life topology: +---------------------------------------------------------------+ | LS1028A | | +------------------------------+ | | | DSA master for Felix | | | |(internal ENETC port 2: eno2))| | | +------------+------------------------------+-------------+ | | | Felix embedded L2 switch | | | | | | | | +--------------+ +--------------+ +--------------+ | | | | |DSA master for| |DSA master for| |DSA master for| | | | | | SJA1105 1 | | SJA1105 2 | | SJA1105 3 | | | | | |(Felix port 1)| |(Felix port 2)| |(Felix port 3)| | | +--+-+--------------+---+--------------+---+--------------+--+--+ +-----------------------+ +-----------------------+ +-----------------------+ | SJA1105 switch 1 | | SJA1105 switch 2 | | SJA1105 switch 3 | +-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+ |sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| |sw3p0|sw3p1|sw3p2|sw3p3| +-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+ The above can be described in the device tree as follows (obviously not complete): mscc_felix { dsa,member = <0 0>; ports { port@4 { ethernet = <&enetc_port2>; }; }; }; sja1105_switch1 { dsa,member = <1 1>; ports { port@4 { ethernet = <&mscc_felix_port1>; }; }; }; sja1105_switch2 { dsa,member = <2 2>; ports { port@4 { ethernet = <&mscc_felix_port2>; }; }; }; sja1105_switch3 { dsa,member = <3 3>; ports { port@4 { ethernet = <&mscc_felix_port3>; }; }; }; Basically we instantiate one DSA switch tree for every hardware switch in the system, but we still give them globally unique switch IDs (will come back to that later). Having 3 disjoint switch trees makes the tagger drivers "just work", because net devices are registered for the 3 Felix DSA master ports, and they are also DSA slave ports to the ENETC port. So packets received on the ENETC port are stripped of their stacked DSA tags one by one. Currently, hardware bridging between ports on the same sja1105 chip is possible, but switching between sja1105 ports on different chips is handled by the software bridge. This is fine, but we can do better. In fact, the dsa_8021q tag used by sja1105 is compatible with cascading. In other words, a sja1105 switch can correctly parse and route a packet containing a dsa_8021q tag. So if we could enable hardware bridging on the Felix DSA master ports, cross-chip bridging could be completely offloaded. Such as system would be used as follows: ip link add dev br0 type bridge && ip link set dev br0 up for port in sw0p0 sw0p1 sw0p2 sw0p3 \ sw1p0 sw1p1 sw1p2 sw1p3 \ sw2p0 sw2p1 sw2p2 sw2p3; do ip link set dev $port master br0 done The above makes switching between ports on the same row be performed in hardware, and between ports on different rows in software. Now assume the Felix switch ports are called swp0, swp1, swp2. By running the following extra commands: ip link add dev br1 type bridge && ip link set dev br1 up for port in swp0 swp1 swp2; do ip link set dev $port master br1 done the CPU no longer sees packets which traverse sja1105 switch boundaries and can be forwarded directly by Felix. The br1 bridge would not be used for any sort of traffic termination. For this to work, we need to give drivers an opportunity to listen for bridging events on DSA trees other than their own, and pass that other tree index as argument. I have made the assumption, for the moment, that the other existing DSA notifiers don't need to be broadcast to other trees. That assumption might turn out to be incorrect. But in the meantime, introduce a dsa_broadcast function, similar in purpose to dsa_port_notify, which is used only by the bridging notifiers. Signed-off-by: -
Vladimir Oltean authored
Commit 8db0a2ee ("net: bridge: reject DSA-enabled master netdevices as bridge members") added a special check in br_if.c in order to check for a DSA master network device with a tagging protocol configured. This was done because back then, such devices, once enslaved in a bridge would become inoperative and would not pass DSA tagged traffic anymore due to br_handle_frame returning RX_HANDLER_CONSUMED. But right now we have valid use cases which do require bridging of DSA masters. One such example is when the DSA master ports are DSA switch ports themselves (in a disjoint tree setup). This should be completely equivalent, functionally speaking, from having multiple DSA switches hanging off of the ports of a switchdev driver. So we should allow the enslaving of DSA tagged master network devices. Instead of the regular br_handle_frame(), install a new function br_handle_frame_dummy() on these DSA masters, which returns RX_HANDLER_PASS in order to call into the DSA specific tagging protocol handlers, and lift the restriction from br_add_if. Suggested-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Suggested-by:
-
Jakub Kicinski authored
Huazhong Tan says: ==================== net: hns3: misc updates for -next This patchset includes some misc updates for the HNS3 ethernet driver. #1 & #2 add two cleanups. #3 provides an interface for the client to query the CMDQ's status. #4 adds a little optimization about debugfs. #5 prevents 1000M auto-negotiation off setting. ==================== Signed-off-by: -
Yufeng Mo authored
The 802.3 specification does not specify the behavior of auto-negotiation off with 1000M in PHY. Therefore, some PHY compatibility issues occur. This patch forbids the setting of this unreasonable mode by ethtool in driver. Signed-off-by:
Yufeng Mo <moyufeng@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Yufeng Mo authored
This patch optimizes the judgment of the input parameters of dump ncl config by checking the number and value of the input parameters apart. It's clearer and more reasonable. Signed-off-by:
-
Huazhong Tan authored
This patch provides a new interface for the client to query whether CMDQ is ready to work. Signed-off-by:
-
Huazhong Tan authored
According to the UM, command 0x0B03 and 0x0B13 are used to query the statistics about TX and RX, not the status, so modifies the unsuitable macro name of these two command. Signed-off-by:
-
Huazhong Tan authored
HCLGE_MISC_VECTOR_INT_STS and HCLGE_VECTOR_PF_OTHER_INT_STS_REG both represent the misc interrupt status register(0x20800), so removes HCLGE_VECTOR_PF_OTHER_INT_STS_REG and replaces it with HCLGE_MISC_VECTOR_INT_STS. Signed-off-by:
-
- 10 May, 2020 17 commits
-
-
Jakub Kicinski authored
Andrew Lunn says: ==================== Ethernet Cable test support any copper Ethernet PHY have support for performing diagnostics of the cable. Are the cable shorted, broken, not plugged into anything at the other end? And they can report roughly how far along the cable any fault is. Add infrastructure in ethtool and phylib support for triggering a cable test and reporting the results. The Marvell 1G PHY driver is then extended to make use of this infrastructure. For testing, a modified ethtool(1) can be found here: https://github.com/lunn/ethtool.git feature/cable-test-v4. This also contains extra code for TDR dump, which will be added to the kernel in a later patch series. Thanks to Chris Healy for extensive testing. v2: See individual patches but: Remove _REPLY messages Change length into a u32 Grammar fixes Rename functions for consistency Extack for cable test already running Remove ethnl_cable_test_act_ops Add status attributes Rename pairs from numbers to letters v3: See individual patches but: Remove ETHTOOL_MSG_CABLE_TEST_ACT_REPLY from documentation Remove unused cable_test_get_policy Fixed example in document Add ETHTOOL_A_CABLE_NEST_* enum Add ETHTOOL_MSG_CABLE_TEST_NTF to documentation Poison phydev->skb Return -EMSGSIZE when ethnl_bcastmsg_put() fails Return valid error code when nla_nest_start() fails Use u8 for results Actually put u32 length into message s/mavell/marvell/g Remove include of <uapi/linux/ethtool_netlink.h> EMSGSIZE when ethnl_bcastmsg_put() fails Print an error message on failure, since this is a void function. v4: See individual patches but: Remove unwanted blank line ENOTSUPP->EOPNOTSUPP Move EINVAL->EMSGSIZE fix to correct patch ==================== Signed-off-by:
-
Andrew Lunn authored
Given that it takes time to run a cable test, send a notify message at the start, as well as when it is completed. v3: EMSGSIZE when ethnl_bcastmsg_put() fails Print an error message on failure, since this is a void function. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Michal Kubecek <mkubecek@suse.cz> Reviewed-by:
-
Andrew Lunn authored
Since running a cable test is disruptive, put the interface into operative state testing while the test is running. Signed-off-by:
-
Andrew Lunn authored
The Marvell PHYs have a couple of different register sets for performing cable tests. Page 7 provides the simplest to use. v3: s/mavell/marvell/g Remove include of <uapi/linux/ethtool_netlink.h> Signed-off-by:
-
Andrew Lunn authored
The PHY drivers can use these helpers for reporting the results. The results get translated into netlink attributes which are added to the pre-allocated skbuf. v3: Poison phydev->skb Return -EMSGSIZE when ethnl_bcastmsg_put() fails Return valid error code when nla_nest_start() fails Use u8 for results Actually put u32 length into message v4: s/ENOTSUPP/EOPNOTSUPP/g Signed-off-by:
-
Andrew Lunn authored
Provide infrastructure for PHY drivers to report the cable test results. A netlink skb is associated to the phydev. Helpers will be added which can add results to this skb. Once the test has finished the results are sent to user space. When netlink ethtool is not part of the kernel configuration stubs are provided. It is also impossible to trigger a cable test, so the error code returned by the alloc function is of no consequence. v2: Include the status complete in the netlink notification message v4: Replace -EINVAL with -EMSGSIZE Signed-off-by:
-
Andrew Lunn authored
Make some helpers for building ethtool netlink messages available outside the compilation unit, so they can be used for building messages which are not simple get/set. Signed-off-by:
-
Andrew Lunn authored
Add the attributes needed to report cable test results to userspace. The reports are expected to be per twisted pair. A nested property per pair can report the result of the cable test. A nested property can also report the length of the cable to any fault. v2: Grammar fixes Change length from u16 to u32 s/DEV/HEADER/g Add status attributes Rename pairs from numbers to letters. v3: Fixed example in document Add ETHTOOL_A_CABLE_NEST_* enum Add ETHTOOL_MSG_CABLE_TEST_NTF to documentation Signed-off-by:
-
Andrew Lunn authored
Add new ethtool netlink calls to trigger the starting of a PHY cable test. Add Kconfig'ury to ETHTOOL_NETLINK so that PHYLIB is not a module when ETHTOOL_NETLINK is builtin, which would result in kernel linking errors. v2: Remove unwanted white space change Remove ethnl_cable_test_act_ops and use doit handler Rename cable_test_set_policy cable_test_act_policy Remove ETHTOOL_MSG_CABLE_TEST_ACT_REPLY v3: Remove ETHTOOL_MSG_CABLE_TEST_ACT_REPLY from documentation Remove unused cable_test_get_policy Add Reviewed-by tags v4: Remove unwanted blank line Signed-off-by:
-
Andrew Lunn authored
Some PHYs are not capable of generating interrupts when a cable test finished. They do however support interrupts for normal operations, like link up/down. As such, the PHY state machine would normally not poll the PHY. Add support for indicating the PHY state machine must poll the PHY when performing a cable test. Signed-off-by:
-
Andrew Lunn authored
Running a cable test is desruptive to normal operation of the PHY and can take a 5 to 10 seconds to complete. The RTNL lock cannot be held for this amount of time, and add a new state to the state machine for running a cable test. The driver is expected to implement two functions. The first is used to start a cable test. Once the test has started, it should return. The second function is called once per second, or on interrupt to check if the cable test is complete, and to allow the PHY to report the status. v2: Rename phy_cable_test_abort to phy_abort_cable_test Return different extack when already running test Use phy_init_hw() to reset the PHY Reviewed-by:
-
Colin Ian King authored
The variable status is being initializeed 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") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Colin Ian King authored
The variable ret is being initializeed 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") Signed-off-by: -
Colin Ian King authored
The variable ret is being initializeed 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") Signed-off-by: -
kbuild test robot authored
drivers/net/dsa/sja1105/sja1105_ethtool.c:481:11-12: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Fixes: ae1804de ("dsa: sja1105: dynamically allocate stats structure") CC: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
Kevin Hao authored
In the current codes, the octeontx2 uses its own method to allocate the pool buffers, but there are some issues in this implementation. 1. We have to run the otx2_get_page() for each allocation cycle and this is pretty error prone. As I can see there is no invocation of the otx2_get_page() in otx2_pool_refill_task(), this will leave the allocated pages have the wrong refcount and may be freed wrongly. 2. It wastes memory. For example, if we only receive one packet in a NAPI RX cycle, and then allocate a 2K buffer with otx2_alloc_rbuf() to refill the pool buffers and leave the remain area of the allocated page wasted. On a kernel with 64K page, 62K area is wasted. IMHO it is really unnecessary to implement our own method for the buffers allocate, we can reuse the napi_alloc_frag() to simplify our code. Signed-off-by:
Kevin Hao <haokexin@gmail.com> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:
-
- 09 May, 2020 10 commits
-
-
Jakub Kicinski authored
Ido Schimmel says: ==================== mlxsw: spectrum: Enforce some HW limitations for matchall TC offload Jiri says: There are some limitations for TC matchall classifier offload that are given by the mlxsw HW dataplane. It is not possible to do sampling on egress and also the mirror/sample vs. ACL (flower) ordering is fixed. So check this and forbid to offload incorrect setup. ==================== Signed-off-by: -
Jiri Pirko authored
Make sure that the drive restricts incorrect order of inserted matchall vs. flower rules. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Jiri Pirko authored
Check that matchall rules with sample actions are not possible to be inserted to egress. Signed-off-by:
-
Jiri Pirko authored
The file is about to contain matchall restrictions too, so change the name to make it more generic. Signed-off-by:
-
Jiri Pirko authored
On ingress, the matchall rules doing mirroring and sampling are offloaded into hardware blocks that are processed before any flower rules. On egress, the matchall mirroring rules are offloaded into hardware block that is processed after all flower rules. Therefore check the priorities of inserted flower rules against existing matchall rules and ensure the correct ordering. Signed-off-by:
-
Jiri Pirko authored
On ingress, the matchall rules doing mirroring and sampling are offloaded into hardware blocks that are processed before any flower rules. On egress, the matchall mirroring rules are offloaded into hardware block that is processed after all flower rules. Therefore check the priorities of inserted matchall rules against existing flower rules and ensure the correct ordering. Signed-off-by:
-
Jiri Pirko authored
Introduce an infrastructure that allows to get minimum and maximum rule priority for specified chain. This is going to be used by a subsequent patch to enforce ordering between flower and matchall filters. Signed-off-by:
-
Jiri Pirko authored
As there are going to be other matchall specific fields in flow structure, put the existing list field into matchall substruct. Signed-off-by:
-
Jiri Pirko authored
Introduce an infrastructure that allows to get minimum and maximum rule priority for specified chain. This is going to be used by a subsequent patch to enforce ordering between flower and matchall filters. Signed-off-by:
-
Jiri Pirko authored
HW supports packet sampling on ingress only. Check and fail if user is adding sample on egress. Signed-off-by:
-
