- Jan 30, 2021
-
-
Vladimir Oltean authored
In expectation of the new tag_ocelot_8021q tagger implementation, we need to be able to do runtime switchover between one tagger and another. So we must structure the existing code for the current NPI-based tagger in a certain way. We move the felix_npi_port_init function in expectation of the future driver configuration necessary for tag_ocelot_8021q: we would like to not have the NPI-related bits interspersed with the tag_8021q bits. The conversion from this: ocelot_write_rix(ocelot, ANA_PGID_PGID_PGID(GENMASK(ocelot->num_phys_ports, 0)), ANA_PGID_PGID, PGID_UC); to this: cpu_flood = ANA_PGID_PGID_PGID(BIT(ocelot->num_phys_ports)); ocelot_rmw_rix(ocelot, cpu_flood, cpu_flood, ANA_PGID_PGID, PGID_UC); is perhaps non-trivial, but is nonetheless non-functional. The PGID_UC (replicator for unknown unicast) is already configured out of hardware reset to flood to all ports except ocelot->num_phys_ports (the CPU port module). All we change is that we use a read-modify-write to only add the CPU port module to the unknown unicast replicator, as opposed to doing a full write to the register. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Vladimir Oltean authored
Currently DSA exposes the following sysfs: $ cat /sys/class/net/eno2/dsa/tagging ocelot which is a read-only device attribute, introduced in the kernel as commit 98cdb480 ("net: dsa: Expose tagging protocol to user-space"), and used by libpcap since its commit 993db3800d7d ("Add support for DSA link-layer types"). It would be nice if we could extend this device attribute by making it writable: $ echo ocelot-8021q > /sys/class/net/eno2/dsa/tagging This is useful with DSA switches that can make use of more than one tagging protocol. It may be useful in dsa_loop in the future too, to perform offline testing of various taggers, or for changing between dsa and edsa on Marvell switches, if that is desirable. In terms of implementation, drivers can support this feature by implementing .change_tag_protocol, which should always leave the switch in a consistent state: either with the new protocol if things went well, or with the old one if something failed. Teardown of the old protocol, if necessary, must be handled by the driver. Some things remain as before: - The .get_tag_protocol is currently only called at probe time, to load the initial tagging protocol driver. Nonetheless, new drivers should report the tagging protocol in current use now. - The driver should manage by itself the initial setup of tagging protocol, no later than the .setup() method, as well as destroying resources used by the last tagger in use, no earlier than the .teardown() method. For multi-switch DSA trees, error handling is a bit more complicated, since e.g. the 5th out of 7 switches may fail to change the tag protocol. When that happens, a revert to the original tag protocol is attempted, but that may fail too, leaving the tree in an inconsistent state despite each individual switch implementing .change_tag_protocol transactionally. Since the intersection between drivers that implement .change_tag_protocol and drivers that support D in DSA is currently the empty set, the possibility for this error to happen is ignored for now. Testing: $ insmod mscc_felix.ko [ 79.549784] mscc_felix 0000:00:00.5: Adding to iommu group 14 [ 79.565712] mscc_felix 0000:00:00.5: Failed to register DSA switch: -517 $ insmod tag_ocelot.ko $ rmmod mscc_felix.ko $ insmod mscc_felix.ko [ 97.261724] libphy: VSC9959 internal MDIO bus: probed [ 97.267363] mscc_felix 0000:00:00.5: Found PCS at internal MDIO address 0 [ 97.274998] mscc_felix 0000:00:00.5: Found PCS at internal MDIO address 1 [ 97.282561] mscc_felix 0000:00:00.5: Found PCS at internal MDIO address 2 [ 97.289700] mscc_felix 0000:00:00.5: Found PCS at internal MDIO address 3 [ 97.599163] mscc_felix 0000:00:00.5 swp0 (uninitialized): PHY [0000:00:00.3:10] driver [Microsemi GE VSC8514 SyncE] (irq=POLL) [ 97.862034] mscc_felix 0000:00:00.5 swp1 (uninitialized): PHY [0000:00:00.3:11] driver [Microsemi GE VSC8514 SyncE] (irq=POLL) [ 97.950731] mscc_felix 0000:00:00.5 swp0: configuring for inband/qsgmii link mode [ 97.964278] 8021q: adding VLAN 0 to HW filter on device swp0 [ 98.146161] mscc_felix 0000:00:00.5 swp2 (uninitialized): PHY [0000:00:00.3:12] driver [Microsemi GE VSC8514 SyncE] (irq=POLL) [ 98.238649] mscc_felix 0000:00:00.5 swp1: configuring for inband/qsgmii link mode [ 98.251845] 8021q: adding VLAN 0 to HW filter on device swp1 [ 98.433916] mscc_felix 0000:00:00.5 swp3 (uninitialized): PHY [0000:00:00.3:13] driver [Microsemi GE VSC8514 SyncE] (irq=POLL) [ 98.485542] mscc_felix 0000:00:00.5: configuring for fixed/internal link mode [ 98.503584] mscc_felix 0000:00:00.5: Link is Up - 2.5Gbps/Full - flow control rx/tx [ 98.527948] device eno2 entered promiscuous mode [ 98.544755] DSA: tree 0 setup $ ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: seq=0 ttl=64 time=2.337 ms 64 bytes from 10.0.0.1: seq=1 ttl=64 time=0.754 ms ^C - 10.0.0.1 ping statistics - 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.754/1.545/2.337 ms $ cat /sys/class/net/eno2/dsa/tagging ocelot $ cat ./test_ocelot_8021q.sh #!/bin/bash ip link set swp0 down ip link set swp1 down ip link set swp2 down ip link set swp3 down ip link set swp5 down ip link set eno2 down echo ocelot-8021q > /sys/class/net/eno2/dsa/tagging ip link set eno2 up ip link set swp0 up ip link set swp1 up ip link set swp2 up ip link set swp3 up ip link set swp5 up $ ./test_ocelot_8021q.sh ./test_ocelot_8021q.sh: line 9: echo: write error: Protocol not available $ rmmod tag_ocelot.ko rmmod: can't unload module 'tag_ocelot': Resource temporarily unavailable $ insmod tag_ocelot_8021q.ko $ ./test_ocelot_8021q.sh $ cat /sys/class/net/eno2/dsa/tagging ocelot-8021q $ rmmod tag_ocelot.ko $ rmmod tag_ocelot_8021q.ko rmmod: can't unload module 'tag_ocelot_8021q': Resource temporarily unavailable $ ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: seq=0 ttl=64 time=0.953 ms 64 bytes from 10.0.0.1: seq=1 ttl=64 time=0.787 ms 64 bytes from 10.0.0.1: seq=2 ttl=64 time=0.771 ms $ rmmod mscc_felix.ko [ 645.544426] mscc_felix 0000:00:00.5: Link is Down [ 645.838608] DSA: tree 0 torn down $ rmmod tag_ocelot_8021q.ko Signed-off-by:
-
Vladimir Oltean authored
Cascading DSA switches can be done multiple ways. There is the brute force approach / tag stacking, where one upstream switch, located between leaf switches and the host Ethernet controller, will just happily transport the DSA header of those leaf switches as payload. For this kind of setups, DSA works without any special kind of treatment compared to a single switch - they just aren't aware of each other. Then there's the approach where the upstream switch understands the tags it transports from its leaves below, as it doesn't push a tag of its own, but it routes based on the source port & switch id information present in that tag (as opposed to DMAC & VID) and it strips the tag when egressing a front-facing port. Currently only Marvell implements the latter, and Marvell DSA trees contain only Marvell switches. So it is safe to say that DSA trees already have a single tag protocol shared by all switches, and in fact this is what makes the switches able to understand each other. This fact is also implied by the fact that currently, the tagging protocol is reported as part of a sysfs installed on the DSA master and not per port, so it must be the same for all the ports connected to that DSA master regardless of the switch that they belong to. It's time to make this official and enforce it (yes, this also means we won't have any "switch understands tag to some extent but is not able to speak it" hardware oddities that we'll support in the future). This is needed due to the imminent introduction of the dsa_switch_ops:: change_tag_protocol driver API. When that is introduced, we'll have to notify switches of the tagging protocol that they're configured to use. Currently the tag_ops structure pointer is held only for CPU ports. But there are switches which don't have CPU ports and nonetheless still need to be configured. These would be Marvell leaf switches whose upstream port is just a DSA link. How do we inform these of their tagging protocol setup/deletion? One answer to the above would be: iterate through the DSA switch tree's ports once, list the CPU ports, get their tag_ops, then iterate again now that we have it, and notify everybody of that tag_ops. But what to do if conflicts appear between one cpu_dp->tag_ops and another? There's no escaping the fact that conflict resolution needs to be done, so we can be upfront about it. Ease our work and just keep the master copy of the tag_ops inside the struct dsa_switch_tree. Reference counting is now moved to be per-tree too, instead of per-CPU port. There are many places in the data path that access master->dsa_ptr->tag_ops and we would introduce unnecessary performance penalty going through yet another indirection, so keep those right where they are. Signed-off-by:
-
Vladimir Oltean authored
The existence of dsa_broadcast has generated some confusion in the past: https://www.mail-archive.com/netdev@vger.kernel.org/msg365042.html So let's document the existing dsa_port_notify and dsa_broadcast functions and explain when each of them should be used. Also, in fact, the in-between function has always been there but was lacking a name, and is the main reason for this patch: dsa_tree_notify. Refactor dsa_broadcast to use it. This patch also moves dsa_broadcast (a top-level function) to dsa2.c, where it really belonged in the first place, but had no companion so it stood with dsa_port_notify. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
Context: Ocelot switches put the injection/extraction frame header in front of the Ethernet header. When used in NPI mode, a DSA master would see junk instead of the destination MAC address, and it would most likely drop the packets. So the Ocelot frame header can have an optional prefix, which is just "ff:ff:ff:ff:ff:fe > ff:ff:ff:ff:ff:ff" padding put before the actual tag (still before the real Ethernet header) such that the DSA master thinks it's looking at a broadcast frame with a strange EtherType. Unfortunately, a lesson learned in commit 69df578c ("net: mscc: ocelot: eliminate confusion between CPU and NPI port") seems to have been forgotten in the meanwhile. The CPU port module and the NPI port have independent settings for the length of the tag prefix. However, the driver is using the same variable to program both of them. There is no reason really to use any tag prefix with the CPU port module, since that is not connected to any Ethernet port. So this patch makes the inj_prefix and xtr_prefix variables apply only to the NPI port (which the switchdev ocelot_vsc7514 driver does not use). Signed-off-by:
-
Vladimir Oltean authored
Applying the bridge forwarding mask currently is done only on the STP state changes for any port. But it depends on both STP state changes, and bonding interface state changes. Export the bit that recalculates the forwarding mask so that it could be reused, and call it when a port starts and stops offloading a bonding interface. Now that the logic is split into a separate function, we can rename "p" into "port", since the "port" variable was already taken in ocelot_bridge_stp_state_set. Also, we can rename "i" into "lag", to make it more clear what is it that we're iterating through. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by:
-
Vladimir Oltean authored
We will be adding some private VCAP filters that should not interfere in any way with the filters added using tc-flower. So we need to allocate some IDs which will not be used by tc. Currently ocelot uses an u32 id derived from the flow cookie, which in itself is an unsigned long. This is a problem in itself, since on 64 bit systems, sizeof(unsigned long)=8, so the driver is already truncating these. Create a struct ocelot_vcap_id which contains the full unsigned long cookie from tc, as well as a boolean that is supposed to namespace the filters added by tc with the ones that aren't. Signed-off-by:
-
Vladimir Oltean authored
The Felix driver will need to preinstall some VCAP filters for its tag_8021q implementation (outside of the tc-flower offload logic), so these need to be exported to the common includes. Signed-off-by:
-
Vladimir Oltean authored
The sja1105 implementation can be blind about this, but the felix driver doesn't do exactly what it's being told, so it needs to know whether it is a TX or an RX VLAN, so it can install the appropriate type of TCAM rule. Signed-off-by:
-
Ronak Doshi authored
buf_info structures in RX & TX queues are private driver data that do not need to be visible to the device. Although there is physical address and length in the queue descriptor that points to these structures, their layout is not standardized, and device never looks at them. So lets allocate these structures in non-DMA-able memory, and fill physical address as all-ones and length as zero in the queue descriptor. That should alleviate worries brought by Martin Radev in https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20210104/022829.html that malicious vmxnet3 device could subvert SVM/TDX guarantees. Signed-off-by:
Petr Vandrovec <petr@vmware.com> Signed-off-by:
Ronak Doshi <doshir@vmware.com> Signed-off-by:
-
Kurt Kanzenbach authored
Add missing dependency to TAPRIO to avoid build failures such as: |ERROR: modpost: "taprio_offload_get" [drivers/net/dsa/hirschmann/hellcreek_sw.ko] undefined! |ERROR: modpost: "taprio_offload_free" [drivers/net/dsa/hirschmann/hellcreek_sw.ko] undefined! Fixes: 24dfc6eb ("net: dsa: hellcreek: Add TAPRIO offloading support") Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Link: https://lore.kernel.org/r/20210128163338.22665-1-kurt@linutronix.de Signed-off-by:
-
- Jan 29, 2021
-
-
Eric Dumazet authored
Use cache friendly helpers to better use cpu caches while reading /proc/net/netstat Tested on a platform with 256 threads (AMD Rome) Before: 305 usec spent in netstat_seq_show() After: 130 usec spent in netstat_seq_show() Signed-off-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20210128162145.1703601-1-eric.dumazet@gmail.com Signed-off-by:
-
Kuniyuki Iwashima authored
The commit 41b14fb8 ("net: Do not clear the sock TX queue in sk_set_socket()") removes sk_tx_queue_clear() from sk_set_socket() and adds it instead in sk_alloc() and sk_clone_lock() to fix an issue introduced in the commit e022f0b4 ("net: Introduce sk_tx_queue_mapping"). On the other hand, the original commit had already put sk_tx_queue_clear() in sk_prot_alloc(): the callee of sk_alloc() and sk_clone_lock(). Thus sk_tx_queue_clear() is called twice in each path. If we remove sk_tx_queue_clear() in sk_alloc() and sk_clone_lock(), it currently works well because (i) sk_tx_queue_mapping is defined between sk_dontcopy_begin and sk_dontcopy_end, and (ii) sock_copy() called after sk_prot_alloc() in sk_clone_lock() does not overwrite sk_tx_queue_mapping. However, if we move sk_tx_queue_mapping out of the no copy area, it introduces a bug unintentionally. Therefore, this patch adds a compile-time check to take care of the order of sock_copy() and sk_tx_queue_clear() and removes sk_tx_queue_clear() from sk_prot_alloc() so that it does the only allocation and its callers initialize fields. CC: Boris Pismenny <borisp@mellanox.com> Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.co.jp> Acked-by:
Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20210128150217.6060-1-kuniyu@amazon.co.jp Signed-off-by:
-
Jakub Kicinski authored
Huazhong Tan says: ==================== net: hns3: updates for -next This patchset adds dump tm info of nodes, priority and qset in debugfs. Three debugfs files tm_nodes, tm_priority and tm_qset are created in new tm directory, and use cat command to dump their info, for examples: $ cat tm_nodes BASE_ID MAX_NUM PG 0 8 PRI 0 8 QSET 0 8 QUEUE 0 1024 $ cat tm_priority ID MODE DWRR C_IR_B C_IR_U C_IR_S C_BS_B C_BS_S C_FLAG C_RATE(Mbps) P_IR_B P_IR_U P_IR_S P_BS_B P_BS_S P_FLAG P_RATE(Mbps) 0000 dwrr 100 0 0 0 5 20 0 0 150 7 0 5 20 0 0 0001 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0002 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0003 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0004 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0005 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0006 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0007 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 $ cat tm_qset ID MAP_PRI LINK_VLD MODE DWRR 0000 0 1 dwrr 100 0001 0 0 sp 0 0002 0 0 sp 0 0003 0 0 sp 0 0004 0 0 sp 0 0005 0 0 sp 0 0006 0 0 sp 0 change log: V2: add readonly files for dump all nodes, priority and qset info suggested by Jakub Kicinski. previous version: V1: https://patchwork.kernel.org/project/netdevbpf/patch/1610694569-43099-1-git-send-email-tanhuazhong@huawei.com/ ==================== Link: https://lore.kernel.org/r/1611834696-56207-1-git-send-email-tanhuazhong@huawei.com Signed-off-by: -
Guangbin Huang authored
In order to query tm info of nodes, priority and qset for debugging, adds three debugfs files tm_nodes, tm_priority and tm_qset in newly created tm directory. Unlike previous debugfs commands, these three files just support read ops, so they only support to use cat command to dump their info. The new tm file style is acccording to suggestion from Jakub Kicinski's opinion as link https://lkml.org/lkml/2020/9/29/2101 . Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Guangbin Huang authored
Add some interfaces to get information of tm priority and qset, then they can be used by debugfs. Signed-off-by:
-
Jakub Kicinski authored
Xin Long says: ==================== net: add support for ip generic checksum offload for gre This patchset it to add ip generic csum processing first in skb_csum_hwoffload_help() in Patch 1/2 and then add csum offload support for GRE header in Patch 2/2. ==================== Link: https://lore.kernel.org/r/cover.1611825446.git.lucien.xin@gmail.com Signed-off-by:
-
Xin Long authored
This patch is to add csum offload support for gre header: On the TX path in gre_build_header(), when CHECKSUM_PARTIAL's set for inner proto, it will calculate the csum for outer proto, and inner csum will be offloaded later. Otherwise, CHECKSUM_PARTIAL and csum_start/offset will be set for outer proto, and the outer csum will be offloaded later. On the GSO path in gre_gso_segment(), when CHECKSUM_PARTIAL is not set for inner proto and the hardware supports csum offload, CHECKSUM_PARTIAL and csum_start/offset will be set for outer proto, and outer csum will be offloaded later. Otherwise, it will do csum for outer proto by calling gso_make_checksum(). Note that SCTP has to do the csum by itself for non GSO path in sctp_packet_pack(), as gre_build_header() can't handle the csum with CHECKSUM_PARTIAL set for SCTP CRC csum offload. v1->v2: - remove the SCTP part, as GRE dev doesn't support SCTP CRC CSUM and it will always do checksum for SCTP in sctp_packet_pack() when it's not a GSO packet. Signed-off-by:Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Xin Long authored
NETIF_F_IP|IPV6_CSUM feature flag indicates UDP and TCP csum offload while NETIF_F_HW_CSUM feature flag indicates ip generic csum offload for HW, which includes not only for TCP/UDP csum, but also for other protocols' csum like GRE's. However, in skb_csum_hwoffload_help() it only checks features against NETIF_F_CSUM_MASK(NETIF_F_HW|IP|IPV6_CSUM). So if it's a non TCP/UDP packet and the features doesn't support NETIF_F_HW_CSUM, but supports NETIF_F_IP|IPV6_CSUM only, it would still return 0 and leave the HW to do csum. This patch is to support ip generic csum processing by checking NETIF_F_HW_CSUM for all protocols, and check (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM) only for TCP and UDP. Note that we're using skb->csum_offset to check if it's a TCP/UDP proctol, this might be fragile. However, as Alex said, for now we only have a few L4 protocols that are requesting Tx csum offload, we'd better fix this until a new protocol comes with a same csum offset. v1->v2: - not extend skb->csum_not_inet, but use skb->csum_offset to tell if it's an UDP/TCP csum packet. v2->v3: - add a note in the changelog, as Willem suggested. Suggested-by:Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-5.12-20210129' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== linux-can-next-for-5.12-20210129 All patches are by me and target the mcp251xfd driver. The first 4 patches update the information regarding the "85% of (FSYSCLK/2)" errata. The other 4 are misc cleanups, unitfy error messages, add missing postfix to a macro, simplify the return of a function, and make use of dev_err_probe() in the mcp251xfd_probe() function. ==================== Link: https://lore.kernel.org/r/20210129084302.3040284-1-mkl@pengutronix.de Signed-off-by:
-
Loic Poulain authored
Use the new mhi_get_free_desc_count helper to track queue usage instead of relying on the locally maintained rx_queued count. Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Loic Poulain authored
The RX queue size can be determined at runtime by retrieving the number of available transfer descriptors. Signed-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/mani/mhiJakub Kicinski authored
Needed by mhi-net patches. Signed-off-by: -
Jan Luebbe authored
This section was missed during the conversion to ReST, so convert it in the same style as the surrounding section titles. Signed-off-by:
Jan Luebbe <jlu@pengutronix.de> Link: https://lore.kernel.org/r/20210128111930.29473-1-jlu@pengutronix.de Signed-off-by:
-
dingsenjie authored
Simplify the code by using module_platform_driver macro for octeon_mgmt. Signed-off-by:
dingsenjie <dingsenjie@yulong.com> Link: https://lore.kernel.org/r/20210128035330.17676-1-dingsenjie@163.com Signed-off-by:
-
Emil Renner Berthing authored
This converts the driver to use the new tasklet API introduced in commit 12cc923f ("tasklet: Introduce new initialization API") Signed-off-by:
Emil Renner Berthing <kernel@esmil.dk> Link: https://lore.kernel.org/r/20210127173256.13954-2-kernel@esmil.dk Signed-off-by:
-
Emil Renner Berthing authored
Previously a temporary tasklet structure was initialized on the stack using DECLARE_TASKLET_OLD() and then copied over and modified. Nothing else in the kernel seems to use this pattern, so let's just call tasklet_init() like everyone else. Signed-off-by:
-
Jakub Kicinski authored
Paul Blakey says: ==================== net/sched: cls_flower: Add support for matching on ct_state reply flag This patchset adds software match support and offload of flower match ct_state reply flag (+/-rpl). The first patch adds the definition for the flag and match to flower. Second patch gives the direction of the connection to the offloading drivers via ct_metadata flow offload action. The last patch does offload of this new ct_state by using the supplied connection's direction. ==================== Link: https://lore.kernel.org/r/1611757967-18236-1-git-send-email-paulb@nvidia.com Signed-off-by:
-
Paul Blakey authored
Add support for matching on ct_state reply flag. Example: $ tc filter add dev ens1f0_0 ingress prio 1 chain 1 proto ip flower \ ct_state +trk+est+rpl \ action mirred egress redirect dev ens1f0_1 $ tc filter add dev ens1f0_1 ingress prio 1 chain 1 proto ip flower \ ct_state +trk+est-rpl \ action mirred egress redirect dev ens1f0_0 Signed-off-by:
Paul Blakey <paulb@nvidia.com> Acked-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
-
Paul Blakey authored
Give offloading drivers the direction of the offloaded ct flow, this will be used for matches on direction (ct_state +/-rpl). Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Paul Blakey authored
Add match on the ct_state reply flag. Example: $ tc filter add dev ens1f0_0 ingress prio 1 chain 1 proto ip flower \ ct_state +trk+est+rpl \ action mirred egress redirect dev ens1f0_1 $ tc filter add dev ens1f0_1 ingress prio 1 chain 1 proto ip flower \ ct_state +trk+est-rpl \ action mirred egress redirect dev ens1f0_0 Signed-off-by:
-
Jakub Kicinski authored
Bongsu Jeon says: ==================== Add nci suit and virtual nci device driver 1/2 is the Virtual NCI device driver. 2/2 is the NCI selftest suite ==================== Link: https://lore.kernel.org/r/20210127130829.4026-1-bongsu.jeon@samsung.com Signed-off-by:
-
Bongsu Jeon authored
This is the NCI test suite. It tests the NFC/NCI module using virtual NCI device. Test cases consist of making the virtual NCI device on/off and controlling the device's polling for NCI1.0 and NCI2.0 version. Signed-off-by:
Bongsu Jeon <bongsu.jeon@samsung.com> Signed-off-by:
-
Bongsu Jeon authored
NCI virtual device simulates a NCI device to the user. It can be used to validate the NCI module and applications. This driver supports communication between the virtual NCI device and NCI module. Signed-off-by:
-
Menglong Dong authored
It's better make 'pkt_sk()' inline here, as non-inline function shouldn't occur in headers. Besides, this function is simple enough to be inline. Signed-off-by:
Menglong Dong <dong.menglong@zte.com.cn> Link: https://lore.kernel.org/r/20210127123302.29842-1-dong.menglong@zte.com.cn Signed-off-by:
-
Andrea Parri (Microsoft) authored
Pointers to receive-buffer packets sent by Hyper-V are used within the guest VM. Hyper-V can send packets with erroneous values or modify packet fields after they are processed by the guest. To defend against these scenarios, copy (sections of) the incoming packet after validating their length and offset fields in netvsc_filter_receive(). In this way, the packet can no longer be modified by the host. Reported-by:
Juan Vazquez <juvazq@microsoft.com> Signed-off-by:
Andrea Parri (Microsoft) <parri.andrea@gmail.com> Link: https://lore.kernel.org/r/20210126162907.21056-1-parri.andrea@gmail.com Signed-off-by:
-
Marc Kleine-Budde authored
dev_err_probe() can reduce code size, uniform error handling and record the defer probe reason etc., use it to simplify the code. Link: https://lore.kernel.org/r/20210128104644.2982125-9-mkl@pengutronix.de Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch simplifies the return of the mcp251xfd_chip_clock_enable() function by direct returning the error. Link: https://lore.kernel.org/r/20210128104644.2982125-8-mkl@pengutronix.de Signed-off-by:
-
Marc Kleine-Budde authored
As MCP251XFD_OBJ_FLAGS_DLC is a mask, add the missing _MASK postfix, that all other masks in the driver have. Link: https://lore.kernel.org/r/20210128104644.2982125-7-mkl@pengutronix.de Signed-off-by:
-
Marc Kleine-Budde authored
This patch unifies the error messages: - have a "." and the end of each message - write controller with a small "c", if not the first word of an error message. Link: https://lore.kernel.org/r/20210128104644.2982125-6-mkl@pengutronix.de Signed-off-by:
-
