- 27 Feb, 2020 5 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] 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 <gustavo@embeddedor.com> 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] 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 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] 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:Martin Habets <mhabets@solarflare.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] This issue was detected 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: -
Florian Fainelli authored
This reverts commit 7458bd54 ("net: dsa: bcm_sf2: Also configure Port 5 for 2Gb/sec on 7278") as it causes advanced congestion buffering issues with 7278 switch devices when using their internal Giabit PHY. While this is being debugged, continue with conservative defaults that work and do not cause packet loss. Fixes: 7458bd54 ("net: dsa: bcm_sf2: Also configure Port 5 for 2Gb/sec on 7278") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by:
-
- 26 Feb, 2020 1 commit
-
-
Jiri Pirko authored
Looks like the iavf code actually experienced a race condition, when a developer took code before the check for chain 0 was put to helper. So use tc_cls_can_offload_and_chain0() helper instead of direct check and move the check to _cb() so this is similar to i40e code. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
- 25 Feb, 2020 11 commits
-
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: Implement ACL-dropped packets identification mlxsw hardware allows to insert a ACL-drop action with a value defined by user that would be later on passed with a dropped packet. To implement this, use the existing TC action cookie and pass it to the driver. As the cookie format coming down from TC and the mlxsw HW cookie format is different, do the mapping of these two using idr and rhashtable. The cookie is passed up from the HW through devlink_trap_report() to drop_monitor code. A new metadata type is used for that. Example: $ tc qdisc add dev enp0s16np1 clsact $ tc filter add dev enp0s16np1 ingress protocol ip pref 10 flower skip_sw dst_ip 192.168.1.2 action drop cookie 3b45fa38c8 ^^^^^^^^^^ $ devlink trap set pci/0000:00:10.0 trap acl action trap $ dropwatch Initializing null lookup method dropwatch> set hw true setting hardware drops monitoring to 1 dropwatch> set alertmode packet Setting alert mode Alert mode successfully set dropwatch> start Enabling monitoring... Kernel monitoring activated. Issue Ctrl-C to stop monitoring drop at: ingress_flow_action_drop (acl_drops) origin: hardware input port ifindex: 30 input port name: enp0s16np1 cookie: 3b45fa38c8 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< timestamp: Fri Jan 24 17:10:53 2020 715387671 nsec protocol: 0x800 length: 98 original length: 98 This way the user may insert multiple drop rules and monitor the dropped packets with the information of which action caused the drop. ==================== Signed-off-by: -
Jiri Pirko authored
Extend existing devlink trap test to include metadata type for flow action cookie. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Jiri Pirko authored
Add new trap ACL which reports flow action cookie in a metadata. Allow used to setup the cookie using debugfs file. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Jiri Pirko authored
Use the cookie index received along with the packet to lookup original flow_offload cookie binary and pass it down to devlink_trap_report(). Add "fa_cookie" metadata to the ACL trap. Signed-off-by:
-
Jiri Pirko authored
In case the received packet comes in due to one of ACL discard traps, take the user_def_val_orig_pkt_len field from CQE and store it in skb->cb as ACL cookie index. Signed-off-by:
-
Jiri Pirko authored
Track cookies coming down to driver by flow_offload. Assign a cookie_index to each unique cookie binary. Use previously defined "Trap with userdef" flex action to ask HW to pass cookie_index alongside with the dropped packets. Signed-off-by:
-
Jiri Pirko authored
Expose "Trap action with userdef". It is the same as already defined "Trap action" with a difference that it would ask the policy engine to pass arbitrary value (userdef) alongside with received packets. This would be later on used to carry cookie index. Signed-off-by:
-
Jiri Pirko authored
Add cookie argument to devlink_trap_report() allowing driver to pass in the user cookie. Pass on the cookie down to drop monitor code. Signed-off-by:
-
Jiri Pirko authored
If driver passed along the cookie, push it through Netlink. Signed-off-by:
-
Jiri Pirko authored
Allow driver to indicate cookie metadata for registered traps. Signed-off-by:
-
Jiri Pirko authored
Extend struct flow_action_entry in order to hold TC action cookie specified by user inserting the action. Signed-off-by:
-
- 24 Feb, 2020 23 commits
-
-
David S. Miller authored
Merge tag 'mac80211-next-for-net-next-2020-02-24' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== A new set of changes: * lots of small documentation fixes, from Jérôme Pouiller * beacon protection (BIGTK) support from Jouni Malinen * some initial code for TID configuration, from Tamizh chelvam * I reverted some new API before it's actually used, because it's wrong to mix controlled port and preauth * a few other cleanups/fixes ==================== Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a pr_err message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Ahmad Fatoum authored
The "stm32_pwr_wakeup" is optional per the binding and the driver handles its absence gracefully. Request it with platform_get_irq_byname_optional, so its absence doesn't needlessly clutter the log. Signed-off-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by:
-
Ahmad Fatoum authored
The specification of a "eth-ck" and a "ptp_ref" clock is optional per the binding and the driver handles them gracefully. Demote the output to an info message accordingly. Signed-off-by:
-
David S. Miller authored
Jeremy Linton says: ==================== Add ACPI bindings to the genet This patch series allows the BCM GENET, as used on the RPi4, to attach when booted in an ACPI environment. The DSDT entry to trigger this is seen below. Of note, the first patch adds a small extension to the mdio layer which allows drivers to find the mii_bus without firmware assistance. The fifth patch in the set retrieves the MAC address from the umac registers rather than carrying it directly in the DSDT. This of course requires the firmware to pre-program it, so we continue to fall back on a random one if it appears to be garbage. v1 -> v2: fail on missing phy-mode property replace phy-mode internal property read string with device_get_phy_mode() equivalent rework mac address detection logic so that it merges the acpi/DT case into device_get_mac_address() allowing _DSD mac address properties. some commit messages justifying why phy_find_first() isn't the worst choice for this driver. + Device (ETH0) + { + Name (_HID, "BCM6E4E") + Name (_UID, 0) + Name (_CCA, 0x0) + Method (_STA) + { + Return (0xf) + } + Method (_CRS, 0x0, Serialized) + { + Name (RBUF, ResourceTemplate () + { + Memory32Fixed (ReadWrite, 0xFd580000, 0x10000, ) + Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 0xBD } + Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 0xBE } + }) + Return (RBUF) + } + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "phy-mode", "rgmii-rxid" }, + } + }) + } ==================== Tested-by: -
Jeremy Linton authored
If one types "failed to get enet clock" or similar into google there are ~370k hits. The vast majority are people debugging problems unrelated to this adapter, or bragging about their rpi's. Further, the DT clock bindings here are optional. Given that its not a fatal situation with common DT based systems, lets reduce the severity so people aren't seeing failure messages in everyday operation. Signed-off-by:
Jeremy Linton <jeremy.linton@arm.com> Reviewed-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Acked-by:
-
Jeremy Linton authored
ARM/ACPI machines should utilize self describing hardware when possible. The MAC address on the BCMGENET can be read from the adapter if a full featured firmware has already programmed it. Lets try using the address already programmed, if it appears to be valid. It should be noted that while we move the macaddr logic below the clock and power logic in the driver, none of that code will ever be active in an ACPI environment as the device will be attached to the acpi power domain, and brought to full power with all clocks enabled immediately before the device probe routine is called. One side effect of the above tweak is that while its now possible to read the MAC address via _DSD properties, it should be avoided. Signed-off-by:
-
Jeremy Linton authored
The rpi4 is capable of booting in ACPI mode with the latest edk2-platform commits. As such it would be helpful if the genet platform device were usable. To achieve this we add a new MODULE_DEVICE_TABLE, and convert a few dt specific methods to their generic device_ calls. Until the next patch, ACPI based machines will fallback on random mac addresses. Signed-off-by:
-
Jeremy Linton authored
The unimac mdio driver falls back to scanning the entire bus if its given an appropriate mask. In ACPI mode we expect that the system is well behaved and conforms to recent versions of the specification. We then utilize phy_find_first(), and phy_connect_direct() to find and attach to the discovered phy during net_device open. While its apparently possible to build a genet based device with multiple phys on a single mdio bus, this works for current machines. Further, this driver makes a number of assumptions about the platform device, mac, mdio and phy all being 1:1. Lastly, It also avoids having to create references across the ACPI namespace hierarchy. Signed-off-by:
-
Jeremy Linton authored
The DT phy mode is similar to what we want for ACPI lets factor it out of the of path, and change the of_ call to device_. Signed-off-by:
-
Jeremy Linton authored
It appears most ethernet drivers follow one of two main strategies for mdio bus/phy management. A monolithic model where the net driver itself creates, probes and uses the phy, and one where an external mdio/phy driver instantiates the mdio bus/phy and the net driver only attaches to a known phy. Usually in this latter model the phys are discovered via DT relationships or simply phy name/address hardcoding. This is a shame because modern well behaved mdio buses are self describing and can be probed. The mdio layer itself is fully capable of this, yet there isn't a clean way for a standalone net driver to attach and enumerate the discovered devices. This is because outside of of_mdio_find_bus() there isn't a straightforward way to acquire the mii_bus pointer. So, lets add a mdio_find_bus which can return the mii_bus based only on its name. 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] 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 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] 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 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] 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 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] 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 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] 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: -
David S. Miller authored
Vladimir Oltean says: ==================== Remainder for "DT bindings for Felix DSA switch on LS1028A" This series is the remainder of patchset [0] which has been merged through Shawn Guo's devicetree tree. It contains changes to the PHY mode validation in the Felix driver ("gmii" to "internal") and the documentation for the DT bindings. [0]: https://patchwork.ozlabs.org/cover/1242716/ ==================== Signed-off-by: -
Vladimir Oltean authored
This patch adds the required documentation for the embedded L2 switch inside the NXP LS1028A chip. I've submitted it in the legacy format instead of yaml schema, because DSA itself has not yet been converted to yaml, and this driver defines no custom bindings. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Vladimir Oltean authored
phy-mode = "gmii" is confusing because it may mean that the port supports the 8-bit-wide parallel data interface pinout, which it doesn't. It may also be confusing because one of the "gmii" internal ports is actually overclocked to run at 2.5Gbps (even though, yes, as far as the switch MAC is concerned, it still thinks it's gigabit). So use the phy-mode = "internal" property to describe the internal ports inside the NXP LS1028A chip (the ones facing the ENETC). The change should be fine, because the device tree bindings document is yet to be introduced, and there are no stable DT blobs in use. Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
-
David S. Miller authored
drivers/net/bareudp.c: In function 'bareudp_xmit_skb': drivers/net/bareudp.c:346:9: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized] 346 | return err; | ^~~ drivers/net/bareudp.c: In function 'bareudp6_xmit_skb': drivers/net/bareudp.c:407:9: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized] 407 | return err; Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
David S. Miller authored
Martin Varghese says: ==================== Bare UDP L3 Encapsulation Module There are various L3 encapsulation standards using UDP being discussed to leverage the UDP based load balancing capability of different networks. MPLSoUDP (__ https://tools.ietf.org/html/rfc7510) is one among them. The Bareudp tunnel module provides a generic L3 encapsulation tunnelling support for tunnelling different L3 protocols like MPLS, IP, NSH etc. inside a UDP tunnel. Special Handling ---------------- The bareudp device supports special handling for MPLS & IP as they can have multiple ethertypes. MPLS procotcol can have ethertypes ETH_P_MPLS_UC (unicast) & ETH_P_MPLS_MC (multicast). IP protocol can have ethertypes ETH_P_IP (v4) & ETH_P_IPV6 (v6). This special handling can be enabled only for ethertypes ETH_P_IP & ETH_P_MPLS_UC with a flag called multiproto mode. Usage ------ 1) Device creation & deletion a) ip link add dev bareudp0 type bareudp dstport 6635 ethertype 0x8847. This creates a bareudp tunnel device which tunnels L3 traffic with ethertype 0x8847 (MPLS traffic). The destination port of the UDP header will be set to 6635.The device will listen on UDP port 6635 to receive traffic. b) ip link delete bareudp0 2) Device creation with multiple proto mode enabled There are two ways to create a bareudp device for MPLS & IP with multiproto mode enabled. a) ip link add dev bareudp0 type bareudp dstport 6635 ethertype 0x8847 multiproto b) ip link add dev bareudp0 type bareudp dstport 6635 ethertype mpls 3) Device Usage The bareudp device could be used along with OVS or flower filter in TC. The OVS or TC flower layer must set the tunnel information in SKB dst field before sending packet buffer to the bareudp device for transmission. On reception the bareudp device extracts and stores the tunnel information in SKB dst field before passing the packet buffer to the network stack. Why not FOU ? ------------ FOU by design does l4 encapsulation.It maps udp port to ipproto (IP protocol number for l4 protocol). Bareudp acheives a generic l3 encapsulation.It maps udp port to l3 ethertype. ==================== Signed-off-by:
-
Martin Varghese authored
Special handling is needed in bareudp module for IP & MPLS as they support more than one ethertypes. MPLS has 2 ethertypes. 0x8847 for MPLS unicast and 0x8848 for MPLS multicast. While decapsulating MPLS packet from UDP packet the tunnel destination IP address is checked to determine the ethertype. The ethertype of the packet will be set to 0x8848 if the tunnel destination IP address is a multicast IP address. The ethertype of the packet will be set to 0x8847 if the tunnel destination IP address is a unicast IP address. IP has 2 ethertypes.0x0800 for IPV4 and 0x86dd for IPv6. The version field of the IP header tunnelled will be checked to determine the ethertype. This special handling to tunnel additional ethertypes will be disabled by default and can be enabled using a flag called multiproto. This flag can be used only with ethertypes 0x8847 and 0x0800. Signed-off-by:
Martin Varghese <martin.varghese@nokia.com> Acked-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Martin Varghese authored
The Bareudp tunnel module provides a generic L3 encapsulation tunnelling module for tunnelling different protocols like MPLS, IP,NSH etc inside a UDP tunnel. Signed-off-by:
-
