- 29 Jul, 2021 40 commits
-
-
Shai Malin authored
Removing the qede module version which is not needed and not allowed with inbox drivers. Signed-off-by:
Prabhakar Kushwaha <pkushwaha@marvell.com> Signed-off-by:
Ariel Elior <aelior@marvell.com> Signed-off-by:
Shai Malin <smalin@marvell.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Shai Malin authored
Removing the qed module version which is not needed and not allowed with inbox drivers. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== NXP SJA1105 VLAN regressions These are 3 patches to fix issues seen with some more varied testing done after the changes in the "Traffic termination for sja1105 ports under VLAN-aware bridge" series were made: https://patchwork.kernel.org/project/netdevbpf/cover/20210726165536.1338471-1-vladimir.oltean@nxp.com/ Issue 1: traffic no longer works on a port after leaving a VLAN-aware bridge Issue 2: untagged traffic not dropped if pvid is absent from a VLAN-aware port Issue 3: PTP and STP broken on ports under a VLAN-aware bridge ==================== Signed-off-by:
-
Vladimir Oltean authored
On RX, a control packet with SJA1110 will have: - an in-band control extension (DSA tag) composed of a header and an optional trailer (if it is a timestamp frame). We can (and do) deduce the source port and switch id from this. - a VLAN header, which can either be the tag_8021q RX VLAN (pvid) or the bridge VLAN. The sja1105_vlan_rcv() function attempts to deduce the source port and switch id a second time from this. The basic idea is that even though we don't need the source port information from the tag_8021q header if it's a control packet, we do need to strip that header before we pass it on to the network stack. The problem is that we call sja1105_vlan_rcv for ports under VLAN-aware bridges, and that function tells us it couldn't identify a tag_8021q header, so we need to perform imprecise RX by VID. Well, we don't, because we already know the source port and switch ID. This patch drops the return value from sja1105_vlan_rcv and we just look at the source_port and switch_id values from sja1105_rcv and sja1110_rcv which were initialized to -1. If they are still -1 it means we need to perform imprecise RX. Fixes: 884be12f ("net: dsa: sja1105: add support for imprecise RX") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
Surprisingly, this configuration: ip link add br0 type bridge vlan_filtering 1 ip link set swp2 master br0 bridge vlan del dev swp2 vid 1 still has the sja1105 switch sending untagged packets to the CPU (and failing to decode them, since dsa_find_designated_bridge_port_by_vid searches by VID 1 and rightfully finds no bridge VLAN 1 on a port). Dumping the switch configuration, the VLANs are managed properly: - the pvid of swp2 is 1 in the MAC Configuration Table, but - only the CPU port is in the port membership of VLANID 1 in the VLAN Lookup Table When the ingress packets are tagged with VID 1, they are properly dropped. But when they are untagged, they are able to reach the CPU port. Also, when the pvid in the MAC Configuration Table is changed to e.g. 55 (an unused VLAN), the untagged packets are also dropped. So it looks like: - the switch bypasses ingress VLAN membership checks for untagged traffic - the reason why the untagged traffic is dropped when I make the pvid 55 is due to the lack of valid destination ports in VLAN 55, rather than an ingress membership violation - the ingress VLAN membership cheks are only done for VLAN-tagged traffic Interesting. It looks like there is an explicit bit to drop untagged traffic, so we should probably be using that to preserve user expectations. Note that only VLAN-aware ports should drop untagged packets due to no pvid - when VLAN-unaware, the software bridge doesn't do this even if there is no pvid on any bridge port and on the bridge itself. So the new sja1105_drop_untagged() function cannot simply be called with "false" from sja1105_bridge_vlan_add() and with "true" from sja1105_bridge_vlan_del. Instead, we need to also consider the VLAN awareness state. That means we need to hook the "drop untagged" setting in all the same places where the "commit pvid" logic is, and it needs to factor in all the state when flipping the "drop untagged" bit: is our current pvid in the VLAN Lookup Table, and is the current port in that VLAN's port membership list? VLAN-unaware ports will never drop untagged frames because these checks always succeed by construction, and the tag_8021q VLANs cannot be changed by the user. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
Now that we no longer have the ultra-central sja1105_build_vlan_table(), we need to be more careful about checking all corner cases manually. For example, when a port leaves a VLAN-aware bridge, it becomes standalone so its pvid should become a tag_8021q RX VLAN again. However, sja1105_commit_pvid() only gets called from sja1105_bridge_vlan_add() and from sja1105_vlan_filtering(), and no VLAN awareness change takes place (VLAN filtering is a global setting for sja1105, so the switch remains VLAN-aware overall). This means that we need to put another sja1105_commit_pvid() call in sja1105_bridge_member(). Fixes: 6dfd23d3 ("net: dsa: sja1105: delete vlan delta save/restore logic") Signed-off-by:
-
David S. Miller authored
Jeremy Kerr says: ==================== Add Management Component Transport Protocol support This series adds core MCTP support to the kernel. From the Kconfig description: Management Component Transport Protocol (MCTP) is an in-system protocol for communicating between management controllers and their managed devices (peripherals, host processors, etc.). The protocol is defined by DMTF specification DSP0236. This option enables core MCTP support. For communicating with other devices, you'll want to enable a driver for a specific hardware channel. This implementation allows a sockets-based API for sending and receiving MCTP messages via sendmsg/recvmsg on SOCK_DGRAM sockets. Kernel stack control is all via netlink, using existing RTM_* messages. The userspace ABI change is fairly small; just the necessary AF_/ETH_P_/ARPHDR_ constants, a new sockaddr, and a new netlink attribute. For MAINTAINERS, I've just included netdev@ as the list entry. I'm happy to alter this based on preferences here - an alternative would be the OpenBMC list (the main user of the MCTP interface), or we can create a new list entirely. We have a couple of interface drivers almost ready to go at the moment, but those can wait until the core code has some review. This is v4 of the series; v1 and v2 were both RFC. selinux folks: CCing 01/15 due to the new PF_MCTP protocol family. linux-doc folks: CCing 15/15 for the new MCTP overview document. Review, comments, questions etc. are most welcome. Cheers, Jeremy v2: - change to match spec terminology: controller -> component - require specific capabilities for bind() & sendmsg() - add address and tag defintions to uapi - add selinux AF_MCTP table definitions - remove strict cflags; warnings are present in common headers v3: - require caps for MCTP bind() & send() - comment typo fixes - switch to an array for local EIDs - fix addrinfo dump iteration & error path - add RTM_DELADDR - remove GENMASK() and BIT() from uapi v4: - drop tun patch; that can be submitted separately - keep nipa happy: add maintainer CCs, including doc and selinux - net-next rebase - Include AF_MCTP in af_family_slock_keys and pf_family_names - Introduce MODULE_ definitions earlier - upstream change: set_link_af no longer called with RTNL held - add kdoc for net_device.mctp_ptr - don't inline mctp_rt_match_eid - require rtm_type == RTN_UNICAST in route management handlers - remove unused RTAX policy table - fix mctp_sock->keys rcu annotations - fix spurious rcu_read_unlock in route input ==================== Signed-off-by: -
Jeremy Kerr authored
This change adds a brief document about the sockets API provided for sending and receiving MCTP messages from userspace. This is roughly based on the OpenBMC design document, at: https://github.com/openbmc/docs/blob/master/designs/mctp/mctp-kernel.mdSigned-off-by:
Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by:
-
Matt Johnston authored
Currently we have a compile-time default network (MCTP_INITIAL_DEFAULT_NET). This change introduces a default_net field on the net namespace, allowing future configuration for new interfaces. Signed-off-by:
Matt Johnston <matt@codeconstruct.com.au> Signed-off-by:
-
Matt Johnston authored
Now that we have a neighbour implementation, hook it up to the output path to set the dest hardware address for outgoing packets. Signed-off-by:
-
Jeremy Kerr authored
This change implements MCTP fragmentation (based on route & device MTU), and corresponding reassembly. The MCTP specification only allows for fragmentation on the originating message endpoint, and reassembly on the destination endpoint - intermediate nodes do not need to reassemble/refragment. Consequently, we only fragment in the local transmit path, and reassemble locally-bound packets. Messages are required to be in-order, so we simply cancel reassembly on out-of-order or missing packets. In the fragmentation path, we just break up the message into MTU-sized fragments; the skb structure is a simple copy for now, which we can later improve with a shared data implementation. For reassembly, we keep track of incoming message fragments using the existing tag infrastructure, allocating a key on the (src,dest,tag) tuple, and reassembles matching fragments into a skb->frag_list. Signed-off-by:
-
Jeremy Kerr authored
Start filling-out the socket syscalls: bind, sendmsg & recvmsg. This requires an input route implementation, so we add to mctp_route_input, allowing lookups on binds & message tags. This just handles single-packet messages at present, we will add fragmentation in a future change. Signed-off-by:
-
Matt Johnston authored
This change adds the netlink interfaces for manipulating the MCTP neighbour table. Signed-off-by:
-
Matt Johnston authored
Add an initial neighbour table implementation, to be used in the route output path. Signed-off-by:
-
Matt Johnston authored
This change adds RTM_GETROUTE, RTM_NEWROUTE & RTM_DELROUTE handlers, allowing management of the MCTP route table. Includes changes from Jeremy Kerr <jk@codeconstruct.com.au>. Signed-off-by:
-
Jeremy Kerr authored
Add a simple routing table, and a couple of route output handlers, and the mctp packet_type & handler. Includes changes from Matt Johnston <matt@codeconstruct.com.au>. Signed-off-by:
-
Jeremy Kerr authored
This change adds the infrastructure for managing MCTP netdevices; we add a pointer to the AF_MCTP-specific data to struct netdevice, and hook up the rtnetlink operations for adding and removing addresses. Includes changes from Matt Johnston <matt@codeconstruct.com.au>. Signed-off-by:
-
Jeremy Kerr authored
Add an empty drivers/net/mctp/, for future interface drivers. Signed-off-by:
-
Jeremy Kerr authored
This change introduces the user-visible MCTP header, containing the protocol-specific addressing definitions. Signed-off-by:
-
Jeremy Kerr authored
Simple packet header format as defined by DMTF DSP0236. Signed-off-by:
-
Jeremy Kerr authored
Add an empty socket implementation, plus initialisation/destruction handlers. Signed-off-by:
-
Jeremy Kerr authored
Add basic Kconfig, an initial (empty) af_mctp source object, and {AF,PF}_MCTP definitions, and the required definitions for a new protocol type. Signed-off-by: -
David S. Miller authored
Krzysztof Kozlowski says: ==================== nfc: constify, continued (part 2) On top of: nfc: constify pointed data https://lore.kernel.org/lkml/20210726145224.146006-1-krzysztof.kozlowski@canonical.com/ ==================== Signed-off-by:
-
Krzysztof Kozlowski authored
File-scope struct nfcmrvl_if_ops is not modified so can be made const. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Several functions do not modify pointed data so arguments and local variables can be const for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Several functions do not modify pointed data so arguments and local variables can be const for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Several functions do not modify pointed data so arguments and local variables can be const for correctness and safety. This allows also making file-scope nci_core_get_config_otp_ram_version array const. Signed-off-by:
-
Krzysztof Kozlowski authored
Loop iterators are simple integers, no point to optimize the size and use u8. It only raises the question whether the variable is used in some other context. Signed-off-by:
-
Krzysztof Kozlowski authored
Size of firmware is a type of size_t, so print it directly instead of casting to int. Signed-off-by:
-
Krzysztof Kozlowski authored
nfcsim_abort_cmd() does not modify struct nfcsim, so local variable can be a pointer to const. Signed-off-by:
-
Krzysztof Kozlowski authored
virtual_ncidev_ioctl() does not modify struct nfc_dev, so local variable can be a pointer to const. Signed-off-by:
-
Krzysztof Kozlowski authored
Several functions do not modify pointed data so arguments and local variables can be const for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Several functions do not modify pointed data so arguments and local variables can be const for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
The buffer passed to mei_nfc_send() can be const for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
The struct nfc_dev is not modified by nfc_get_drvdata() and nfc_device_name() so it can be made a const. Signed-off-by:
-
David S. Miller authored
Paolo Abeni says: ==================== sk_buff: optimize GRO for the common case This is a trimmed down revision of "sk_buff: optimize layout for GRO", specifically dropping the changes to the sk_buff layout[1]. This series tries to accomplish 2 goals: - optimize the GRO stage for the most common scenario, avoiding a bunch of conditional and some more code - let owned skbs entering the GRO engine, allowing backpressure in the veth GRO forward path. A new sk_buff flag (!!!) is introduced and maintained for GRO's sake. Such field uses an existing hole, so there is no change to the sk_buff size. [1] two main reasons: - move skb->inner_ field requires some extra care, as some in kernel users access and the fields regardless of skb->encapsulation. - extending secmark size clash with ct and nft uAPIs address the all above is possible, I think, but for sure not in a single series. ==================== Signed-off-by: -
Paolo Abeni authored
Leveraging the previous patch we can now avoid orphaning the skb in the veth gro path, allowing correct backpressure. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Paolo Abeni authored
This change leverages the infrastructure introduced by the previous patches to allow soft devices passing to the GRO engine owned skbs without impacting the fast-path. It's up to the GRO caller ensuring the slow_gro bit validity before invoking the GRO engine. The new helper skb_prepare_for_gro() is introduced for that goal. On slow_gro, skbs are aggregated only with equal sk. Additionally, skb truesize on GRO recycle and free is correctly updated so that sk wmem is not changed by the GRO processing. rfc-> v1: - fixed bad truesize on dev_gro_receive NAPI_FREE - use the existing state bit Signed-off-by:
-
Paolo Abeni authored
After the previous patches, at GRO time, skb->slow_gro is usually 0, unless the packets comes from some H/W offload slowpath or tunnel. We can optimize the GRO code assuming !skb->slow_gro is likely. This remove multiple conditionals in the most common path, at the price of an additional one when we hit the above "slow-paths". Signed-off-by:
-
Paolo Abeni authored
Similar to the previous one, but tracking the active_extensions field status. Signed-off-by:
-
