- 09 Aug, 2023 40 commits
-
-
Vladimir Oltean authored
For offloaded tc-taprio testing with netdevsim, the mock-up PHC driver is used. Suggested-by:
Victor Nogueira <victor@mojatatu.com> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20230807193324.4128292-10-vladimir.oltean@nxp.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Vladimir Oltean authored
To be able to use netdevsim for tc-testing with an offloaded tc-taprio schedule, it needs to report a PTP clock (which it now does), and to accept ndo_setup_tc(TC_SETUP_QDISC_TAPRIO) calls. Since netdevsim has no packet I/O, this doesn't do anything intelligent, it only allows taprio offload code paths to go through some level of automated testing. Signed-off-by:
-
Vladimir Oltean authored
I'd like to make netdevsim offload tc-taprio, but currently, this Qdisc emits a ETHTOOL_GET_TS_INFO call to the driver to make sure that it has a PTP clock, so that it is reasonably capable of offloading the schedule. By using the mock PHC driver, that becomes possible. Hardware timestamping is not necessary, and netdevsim does not support packet I/O anyway. Signed-off-by:
-
Vladimir Oltean authored
There are several cases where virtual net devices may benefit from having a PTP clock, and these have to do with testing. I can see at least netdevsim and veth as potential users of a common mock-up PTP hardware clock driver. The proposed idea is to create an object which emulates PTP clock operations on top of the unadjustable CLOCK_MONOTONIC_RAW plus a software-controlled time domain via a timecounter/cyclecounter and then link that PHC to the netdevsim device. The driver is fully functional for its intended purpose, and it successfully passes the PTP selftests. $ cd tools/testing/selftests/ptp/ $ ./phc.sh /dev/ptp2 TEST: settime [ OK ] TEST: adjtime [ OK ] TEST: adjfreq [ OK ] Signed-off-by:
-
Vladimir Oltean authored
This makes a difference for the software scheduling mode, where dev_queue->qdisc_sleeping is the same as the taprio root Qdisc itself, but when we're talking about what Qdisc and stats get reported for a traffic class, the root taprio isn't what comes to mind, but q->qdiscs[] is. To understand the difference, I've attempted to send 100 packets in software mode through class 8001:5, and recorded the stats before and after the change. Here is before: $ tc -s class show dev eth0 class taprio 8001:1 root leaf 8001: Sent 9400 bytes 100 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:2 root leaf 8001: Sent 9400 bytes 100 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:3 root leaf 8001: Sent 9400 bytes 100 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:4 root leaf 8001: Sent 9400 bytes 100 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:5 root leaf 8001: Sent 9400 bytes 100 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:6 root leaf 8001: Sent 9400 bytes 100 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:7 root leaf 8001: Sent 9400 bytes 100 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:8 root leaf 8001: Sent 9400 bytes 100 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 and here is after: class taprio 8001:1 root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:2 root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:3 root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:4 root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:5 root Sent 9400 bytes 100 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:6 root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:7 root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 class taprio 8001:8 root leaf 800d: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 window_drops 0 The most glaring (and expected) difference is that before, all class stats reported the global stats, whereas now, they really report just the counters for that traffic class. Finally, Pedro Tammela points out that there is a tc selftest which checks specifically which handle do the child Qdiscs corresponding to each class have. That's changing here - taprio no longer reports tcm->tcm_info as the same handle "1:" as itself (the root Qdisc), but 0 (the handle of the default pfifo child Qdiscs). Since iproute2 does not print a child Qdisc handle of 0, adjust the test's expected output. Link: https://lore.kernel.org/netdev/3b83fcf6-a5e8-26fb-8c8a-ec34ec4c3342@mojatatu.com/Signed-off-by:
-
Vladimir Oltean authored
As mentioned in commit af7b29b1 ("Revert "net/sched: taprio: make qdisc_leaf() see the per-netdev-queue pfifo child qdiscs"") - unlike mqprio, taprio doesn't use q->qdiscs[] only as a temporary transport between Qdisc_ops :: init() and Qdisc_ops :: attach(). Delete the comment, which is just stolen from mqprio, but there, the usage patterns are a lot different, and this is nothing but confusing. Signed-off-by:
-
Vladimir Oltean authored
This is another stab at commit 1461d212 ("net/sched: taprio: make qdisc_leaf() see the per-netdev-queue pfifo child qdiscs"), later reverted in commit af7b29b1 ("Revert "net/sched: taprio: make qdisc_leaf() see the per-netdev-queue pfifo child qdiscs""). I believe that the problems that caused the revert were fixed, and thus, this change is identical to the original patch. Its purpose is to properly reject attaching a software taprio child qdisc to a software taprio parent. Because unoffloaded taprio currently reports itself (the root Qdisc) as the return value from qdisc_leaf(), then the process of attaching another taprio as child to a Qdisc class of the root will just result in a Qdisc_ops :: change() call for the root. Whereas that's not we want. We want Qdisc_ops :: init() to be called for the taprio child, in order to give the taprio child a chance to check whether its sch->parent is TC_H_ROOT or not (and reject this configuration). Signed-off-by:
-
Vladimir Oltean authored
Normally, Qdiscs have one reference on them held by their owner and one held for each TXQ to which they are attached, however this is not the case with the children of an offloaded taprio. Instead, the taprio qdisc currently lives in the following fragile equilibrium. In the software scheduling case, taprio attaches itself (the root Qdisc) to all TXQs, thus having a refcount of 1 + the number of TX queues. In this mode, the q->qdiscs[] children are not visible directly to the Qdisc API. The lifetime of the Qdiscs from this private array lasts until qdisc_destroy() -> taprio_destroy(). In the fully offloaded case, the root taprio has a refcount of 1, and all child q->qdiscs[] also have a refcount of 1. The child q->qdiscs[] are attached to the netdev TXQs directly and thus are visible to the Qdisc API, however taprio loses a reference to them very early - during qdisc_graft(parent==NULL) -> taprio_attach(). At that time, taprio frees the q->qdiscs[] array to not leak memory, but interestingly, it does not release a reference on these qdiscs because it doesn't effectively own them - they are created by taprio but owned by the Qdisc core, and will be freed by qdisc_graft(parent==NULL, new==NULL) -> qdisc_put(old) when the Qdisc is deleted or when the child Qdisc is replaced with something else. My interest is to change this equilibrium such that taprio also owns a reference on the q->qdiscs[] child Qdiscs for the lifetime of the root Qdisc, including in full offload mode. I want this because I would like taprio_leaf(), taprio_dump_class(), taprio_dump_class_stats() to have insight into q->qdiscs[] for the software scheduling mode - currently they look at dev_queue->qdisc_sleeping, which is, as mentioned, the same as the root taprio. The following set of changes is necessary: - don't free q->qdiscs[] early in taprio_attach(), free it late in taprio_destroy() for consistency with software mode. But: - currently that's not possible, because taprio doesn't own a reference on q->qdiscs[]. So hold that reference - once during the initial attach() and once during subsequent graft() calls when the child is changed. - always keep track of the current child in q->qdiscs[], even for full offload mode, so that we free in taprio_destroy() what we should, and not something stale. Signed-off-by:
-
Vladimir Oltean authored
This is a simple code transformation with no intended behavior change, just to make it absolutely clear that q->qdiscs[] is only attached to the child taprio classes in full offload mode. Right now we use the q->qdiscs[] variable in taprio_attach() for software mode too, but that is quite confusing and avoidable. We use it only to reach the netdev TX queue, but we could as well just use netdev_get_tx_queue() for that. Signed-off-by:
-
Jakub Kicinski authored
Saeed Mahameed says: ==================== mlx5: Expose NIC temperature via hwmon API Expose NIC temperature by implementing hwmon kernel API, which turns current thermal zone kernel API to redundant. For each one of the supported and exposed thermal diode sensors, expose the following attributes: 1) Input temperature. 2) Highest temperature. 3) Temperature label. 4) Temperature critical max value: refers to the high threshold of Warning Event. Will be exposed as `tempY_crit` hwmon attribute (RO attribute). For example for ConnectX5 HCA's this temperature value will be 105 Celsius, 10 degrees lower than the HW shutdown temperature). 5) Temperature reset history: resets highest temperature. ==================== Link: https://lore.kernel.org/r/20230807180507.22984-1-saeed@kernel.orgSigned-off-by:
-
Adham Faris authored
Expose NIC temperature by implementing hwmon kernel API, which turns current thermal zone kernel API to redundant. For each one of the supported and exposed thermal diode sensors, expose the following attributes: 1) Input temperature. 2) Highest temperature. 3) Temperature label: Depends on the firmware capability, if firmware doesn't support sensors naming, the fallback naming convention would be: "sensorX", where X is the HW spec (MTMP register) sensor index. 4) Temperature critical max value: refers to the high threshold of Warning Event. Will be exposed as `tempY_crit` hwmon attribute (RO attribute). For example for ConnectX5 HCA's this temperature value will be 105 Celsius, 10 degrees lower than the HW shutdown temperature). 5) Temperature reset history: resets highest temperature. For example, for dualport ConnectX5 NIC with a single IC thermal diode sensor will have 2 hwmon directories (one for each PCI function) under "/sys/class/hwmon/hwmon[X,Y]". Listing one of the directories above (hwmonX/Y) generates the corresponding output below: $ grep -H -d skip . /sys/class/hwmon/hwmon0/* Output ======================================================================= /sys/class/hwmon/hwmon0/name:mlx5 /sys/class/hwmon/hwmon0/temp1_crit:105000 /sys/class/hwmon/hwmon0/temp1_highest:48000 /sys/class/hwmon/hwmon0/temp1_input:46000 /sys/class/hwmon/hwmon0/temp1_label:asic grep: /sys/class/hwmon/hwmon0/temp1_reset_history: Permission denied In addition, displaying the sensors data via lm_sensors generates the corresponding output below: $ sensors Output ======================================================================= mlx5-pci-0800 Adapter: PCI adapter asic: +46.0°C (crit = +105.0°C, highest = +48.0°C) mlx5-pci-0801 Adapter: PCI adapter asic: +46.0°C (crit = +105.0°C, highest = +48.0°C) CC: Jean Delvare <jdelvare@suse.com> Signed-off-by:
Adham Faris <afaris@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Gal Pressman <gal@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com> Acked-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20230807180507.22984-3-saeed@kernel.orgSigned-off-by:
-
Adham Faris authored
Make mlx5_query_module_num() defined in port.c, a non-static, so it can be used by other files. CC: Jean Delvare <jdelvare@suse.com> CC: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Nick Desaulniers authored
I'm looking to enable -Wmissing-variable-declarations behind W=1. 0day bot spotted the following instances: net/llc/llc_conn.c:44:5: warning: no previous extern declaration for non-static variable 'sysctl_llc2_ack_timeout' [-Wmissing-variable-declarations] 44 | int sysctl_llc2_ack_timeout = LLC2_ACK_TIME * HZ; | ^ net/llc/llc_conn.c:44:1: note: declare 'static' if the variable is not intended to be used outside of this translation unit 44 | int sysctl_llc2_ack_timeout = LLC2_ACK_TIME * HZ; | ^ net/llc/llc_conn.c:45:5: warning: no previous extern declaration for non-static variable 'sysctl_llc2_p_timeout' [-Wmissing-variable-declarations] 45 | int sysctl_llc2_p_timeout = LLC2_P_TIME * HZ; | ^ net/llc/llc_conn.c:45:1: note: declare 'static' if the variable is not intended to be used outside of this translation unit 45 | int sysctl_llc2_p_timeout = LLC2_P_TIME * HZ; | ^ net/llc/llc_conn.c:46:5: warning: no previous extern declaration for non-static variable 'sysctl_llc2_rej_timeout' [-Wmissing-variable-declarations] 46 | int sysctl_llc2_rej_timeout = LLC2_REJ_TIME * HZ; | ^ net/llc/llc_conn.c:46:1: note: declare 'static' if the variable is not intended to be used outside of this translation unit 46 | int sysctl_llc2_rej_timeout = LLC2_REJ_TIME * HZ; | ^ net/llc/llc_conn.c:47:5: warning: no previous extern declaration for non-static variable 'sysctl_llc2_busy_timeout' [-Wmissing-variable-declarations] 47 | int sysctl_llc2_busy_timeout = LLC2_BUSY_TIME * HZ; | ^ net/llc/llc_conn.c:47:1: note: declare 'static' if the variable is not intended to be used outside of this translation unit 47 | int sysctl_llc2_busy_timeout = LLC2_BUSY_TIME * HZ; | ^ These symbols are referenced by more than one translation unit, so make include the correct header for their declarations. Finally, sort the list of includes to help keep them tidy. Reported-by:kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/llvm/202308081000.tTL1ElTr-lkp@intel.com/Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/20230808-llc_static-v1-1-c140c4c297e4@google.comSigned-off-by:
-
Eric Dumazet authored
IPV6_ADDRFORM socket option is evil, because it can change sock->ops while other threads might read it. Same issue for sk->sk_family being set to AF_INET. Adding READ_ONCE() over sock->ops reads is needed for sockets that might be impacted by IPV6_ADDRFORM. Note that mptcp_is_tcpsk() can also overwrite sock->ops. Adding annotations for all sk->sk_family reads will require more patches :/ BUG: KCSAN: data-race in ____sys_sendmsg / do_ipv6_setsockopt write to 0xffff888109f24ca0 of 8 bytes by task 4470 on cpu 0: do_ipv6_setsockopt+0x2c5e/0x2ce0 net/ipv6/ipv6_sockglue.c:491 ipv6_setsockopt+0x57/0x130 net/ipv6/ipv6_sockglue.c:1012 udpv6_setsockopt+0x95/0xa0 net/ipv6/udp.c:1690 sock_common_setsockopt+0x61/0x70 net/core/sock.c:3663 __sys_setsockopt+0x1c3/0x230 net/socket.c:2273 __do_sys_setsockopt net/socket.c:2284 [inline] __se_sys_setsockopt net/socket.c:2281 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2281 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffff888109f24ca0 of 8 bytes by task 4469 on cpu 1: sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0x349/0x4c0 net/socket.c:2503 ___sys_sendmsg net/socket.c:2557 [inline] __sys_sendmmsg+0x263/0x500 net/socket.c:2643 __do_sys_sendmmsg net/socket.c:2672 [inline] __se_sys_sendmmsg net/socket.c:2669 [inline] __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2669 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0xffffffff850e32b8 -> 0xffffffff850da890 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 4469 Comm: syz-executor.1 Not tainted 6.4.0-rc5-syzkaller-00313-g4c605260 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
-
Jakub Kicinski authored
Li Zetao says: ==================== Remove redundant functions and use generic functions This patch set removes some redundant functions. In the network module, two generic functions are provided to convert u64 value and Ethernet MAC address. Using generic functions helps reduce redundant code and improve code readability. ==================== Link: https://lore.kernel.org/r/20230808114504.4036008-1-lizetao1@huawei.comSigned-off-by:
-
Li Zetao authored
The rvu_npc_exact_mac2u64() is used to convert an Ethernet MAC address into a u64 value, as this is exactly what ether_addr_to_u64() does. Use ether_addr_to_u64() to replace the rvu_npc_exact_mac2u64(). Signed-off-by:
Li Zetao <lizetao1@huawei.com> Acked-by:
Geethasowjanya Akula <gakula@marvell.com> Link: https://lore.kernel.org/r/20230808114504.4036008-4-lizetao1@huawei.comSigned-off-by:
-
Li Zetao authored
Use u64_to_ether_addr() to convert a u64 value to an Ethernet MAC address, instead of directly calculating, as this is exactly what this function does. Signed-off-by:
-
Li Zetao authored
The mac2u64() is used to convert an Ethernet MAC address into a u64 value, as this is exactly what ether_addr_to_u64() does. Similarly, the cfg2mac() is also the case. Use ether_addr_to_u64() and u64_to_ether_addr() instead of these two. Signed-off-by:
-
Jakub Kicinski authored
Petr Machata says: ==================== mlxsw: Set port STP state on bridge enslavement When the first port joins a LAG that already has a bridge upper, an instance of struct mlxsw_sp_bridge_port is created for the LAG to keep track of it as a bridge port. The bridge_port's STP state is initialized to BR_STATE_DISABLED. This made sense previously, because mlxsw would only ever allow a port to join a LAG if the LAG had no uppers. Thus if a bridge_port was instantiated, it must have been because the LAG as such is joining a bridge, and the STP state is correspondingly disabled. However as of commit 2c5ffe8d ("mlxsw: spectrum: Permit enslavement to netdevices with uppers"), mlxsw allows a port to join a LAG that is already a member of a bridge. The STP state may be different than disabled in that case. Initialize it properly by querying the actual state. This bug may cause an issue as traffic on ports attached to a bridged LAG gets dropped on ingress with discard_ingress_general counter bumped. The above fix in patch #1. Patch #2 contains a selftest that would sporadically reproduce the issue. ==================== Link: https://lore.kernel.org/r/cover.1691498735.git.petrm@nvidia.comSigned-off-by:
-
Petr Machata authored
Add a selftest to verify enslavement to a LAG with upper after fresh devlink reload. Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Danielle Ratson <danieller@nvidia.com> Reviewed-by:
-
Petr Machata authored
When the first port joins a LAG that already has a bridge upper, an instance of struct mlxsw_sp_bridge_port is created for the LAG to keep track of it as a bridge port. The bridge_port's STP state is initialized to BR_STATE_DISABLED. This made sense previously, because mlxsw would only ever allow a port to join a LAG if the LAG had no uppers. Thus if a bridge_port was instantiated, it must have been because the LAG as such is joining a bridge, and the STP state is correspondingly disabled. However as of commit 2c5ffe8d ("mlxsw: spectrum: Permit enslavement to netdevices with uppers"), mlxsw allows a port to join a LAG that is already a member of a bridge. The STP state may be different than disabled in that case. Initialize it properly by querying the actual state. This bug may cause an issue as traffic on ports attached to a bridged LAG gets dropped on ingress with discard_ingress_general counter bumped. Fixes: c6514f36 ("Merge branch 'mlxsw-enslavement'") Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
-
Li Zetao authored
Use ether_addr_to_u64() to convert an Ethernet address into a u64 value, instead of directly calculating, as this is exactly what this function does. Signed-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-nextJakub Kicinski authored
Florian Westphal says: ==================== netfilter updates for net-next First 4 Patches, from Yue Haibing, remove unused prototypes in various netfilter headers. Last patch makes nfnetlink_log to always include a packet timestamp, up to now it was only included if the skb had assigned previously. From Maciej Żenczykowski. * tag 'nf-next-2023-08-08' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next: netfilter: nfnetlink_log: always add a timestamp netfilter: h323: Remove unused function declarations netfilter: conntrack: Remove unused function declarations netfilter: helper: Remove unused function declarations netfilter: gre: Remove unused function declaration nf_ct_gre_keymap_flush() ==================== Link: https://lore.kernel.org/r/20230808124159.19046-1-fw@strlen.deSigned-off-by:
-
Ruan Jinjie authored
Use is_zero_ether_addr() instead of ether_addr_equal() to check if the ethernet address is all zeros. Signed-off-by:
Ruan Jinjie <ruanjinjie@huawei.com> Reviewed-by:
-
Jakub Kicinski authored
We're missing empty line between policies. DPLL will need this. Tested-by:
Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://lore.kernel.org/r/20230808200907.1290647-1-kuba@kernel.orgSigned-off-by:
-
Yue Haibing authored
Commit 6bc506b4 ("bridge: switchdev: Add forward mark support for stacked devices") removed the implementation but leave declaration. Signed-off-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
-
Yue Haibing authored
Commit f92e1869 ("Add Mellanox BlueField Gigabit Ethernet driver") declared but never implemented these. Signed-off-by:
Asmaa Mnebhi <asmaa@nvidia.com> Link: https://lore.kernel.org/r/20230808145249.41596-1-yuehaibing@huawei.comSigned-off-by:
-
Yue Haibing authored
Commit 1e2dc145 ("net: ethtool: Add helpers for reporting test results") declared but never implemented these function. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230808144610.19096-1-yuehaibing@huawei.comSigned-off-by:
-
Russell King (Oracle) authored
If we successfully parsed an interface mode with a legacy switch driver, populate that mode into phylink's supported interfaces rather than defaulting to the internal and gmii interfaces. This hasn't caused an issue so far, because when the interface doesn't match a supported one, phylink_validate() doesn't clear the supported mask, but instead returns -EINVAL. phylink_parse_fixedlink() doesn't check this return value, and merely relies on the supported ethtool link modes mask being cleared. Therefore, the fixed link settings end up being allowed despite validation failing. Before this causes a problem, arrange for DSA to more accurately populate phylink's supported interfaces mask so validation can correctly succeed. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/E1qTKdM-003Cpx-Eh@rmk-PC.armlinux.org.ukSigned-off-by:
-
Jiri Pirko authored
When xarray insertion fails, clear the flag. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
-
Jiri Pirko authored
When dont-validate flags are filtered out for do/dump op, the list may be empty. In that case, avoid rendering the validate field. Fixes: fa8ba350 ("ynl-gen-c.py: render netlink policies static for split ops") Signed-off-by:
-
Xiongfeng Wang authored
PCI core API pci_dev_id() can be used to get the BDF number for a pci device. We don't need to compose it manually. Use pci_dev_id() to simplify the code a little bit. Signed-off-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
-
Li Zetao authored
The platform_register_drivers() will set "THIS_MODULE" to driver.owner when register a platform_driver driver, so it is redundant initialization to set driver.owner in the statement. Remove it for clean code. Signed-off-by:
Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Link: https://lore.kernel.org/r/20230808014702.2712699-1-lizetao1@huawei.comSigned-off-by:
-
Yue Haibing authored
Commit 52666986 ("tipc: let broadcast packet reception use new link receive function") declared but never implemented this. Signed-off-by:
-
Daniel Golle authored
Different MT7530 variants require different PHY drivers. Use 'imply' instead of 'select' to relax the dependency on the PHY driver, and choose the appropriate driver. Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Reviewed-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Edward Cree says: ==================== sfc: basic conntrack offload Support offloading tracked connections and matching against them in TC chains on the PF and on representors. Later patch serieses will add NAT and conntrack-on-tunnel-netdevs; keep it simple for now. ==================== Signed-off-by: -
Edward Cree authored
Handle the (comparatively) simple case of a -trk rule on an efx netdev (i.e. not a tunnel decap rule) with ct and goto chain actions. Reviewed-by:
Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Reviewed-by:
Edward Cree <ecree.xilinx@gmail.com> Signed-off-by:
-
Edward Cree authored
Parse ct_state trk/est, mark and zone out of flower keys, and plumb them through to the hardware, performing some minor translations. Nothing can actually hit them yet as we're not offloading any DO_CT actions. Reviewed-by:
-
Edward Cree authored
Map it to an 8-bit recirc_id for use by the hardware. Currently nothing in the driver is offloading 'goto chain' actions, so these rules cannot yet be hit. Reviewed-by:
-
Edward Cree authored
No handling yet for FLOW_ACTION_MANGLE (NAT or NAPT) actions. Reviewed-by:
-
