aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2022-02-22Merge tag 'iwlwifi-next-for-kalle-2022-02-18' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-nextKalle Valo78-944/+2313
iwlwifi patches for v5.18 * Support UHB TAS enablement via BIOS; * Remove a bunch of W=1 warnings; * Add support for channel switch offload; * Support a new FW API command version; * Support 32 Rx AMPDU sessions in newer devices; * Support a few new FW API command versions; * Some debugging infra fixes; * A few fixes in the HE functionality; * Add a few new devices; * A bunch of fixes for W=1 and W=3 warnings; * Add support for a couple of new devices; * Fix a potential buffer underflow; * W=1 warnings clean up continues; * Some improvements and fixes in scanning; * More work on the Bz family of devices; * Add support for band disablement via BIOS; * Bump FW API version; * Fix config structure for one device; * Support a new FW API command version; * Support new queue allocation command; * Some more debugging improvements; * Some other small fixes, clean-ups and improvements.
2022-02-22net: dsa: b53: mark as non-legacyRussell King (Oracle)1-0/+6
The B53 driver does not make use of the speed, duplex, pause or advertisement in its phylink_mac_config() implementation, so it can be marked as a non-legacy driver. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22net: dsa: b53: switch to using phylink_generic_validate()Russell King (Oracle)5-76/+13
Switch the Broadcom b53 driver to using the phylink_generic_validate() implementation by removing its own .phylink_validate method and associated code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22net: dsa: b53: drop use of phylink_helper_basex_speed()Russell King (Oracle)1-2/+0
Now that we have a better method to select SFP interface modes, we no longer need to use phylink_helper_basex_speed() in a driver's validation function. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22net: dsa: b53: populate supported_interfaces and mac_capabilitiesRussell King (Oracle)5-0/+95
Populate the supported interfaces and MAC capabilities for the Broadcom B53 DSA switches in preparation to using these for the generic validation functionality. The interface modes are derived from: - b53_serdes_phylink_validate() - SRAB mux configuration Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22net: dsa: b53: clean up if() condition to be more readableRussell King (Oracle)1-4/+7
I've stared at this if() statement for a while trying to work out if it really does correspond with the comment above, and it does seem to. However, let's make it more readable and phrase it in the same way as the comment. Also add a FIXME into the comment - we appear to deny Gigabit modes for 802.3z interface modes, but 802.3z interface modes only operate at gigabit and above. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21net: dm9051: Fix use after free in dm9051_loop_tx()Dan Carpenter1-1/+3
This code dereferences "skb" after calling dev_kfree_skb(). Fixes: 2dc95a4d30ed ("net: Add dm9051 driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220221105440.GA10045@kili Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-21octeontx2-af: cn10k: add workaround for ptp errataNaveen Mamindlapalli1-7/+80
This patch adds workaround for PTP errata given below. 1. At the time of 1 sec rollover of nano-second counter, the nano-second counter is set to 0. However, it should be set to (existing counter_value - 10^9). This leads to an accumulating error in the timestamp value with each sec rollover. 2. Additionally, the nano-second counter currently is rolling over at 'h3B9A_C9FF. It should roll over at 'h3B9A_CA00. The workaround for issue #1 is to speed up the ptp clock by adjusting PTP_CLOCK_COMP register to the desired value to compensate for the nanoseconds lost per each second. The workaround for issue #2 is to slow down the ptp clock such that the rollover occurs at ~1sec. Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by: Rakesh Babu Saladi <rsaladi2@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21octeontx2-pf: cn10k: add support for new ptp timestamp formatNaveen Mamindlapalli6-3/+75
The cn10k hardware ptp timestamp format has been modified primarily to support 1-step ptp clock. The 64-bit timestamp used by hardware is split into two 32-bit fields, the upper one holds seconds, the lower one nanoseconds. A new register (PTP_CLOCK_SEC) has been added that returns the current seconds value. The nanoseconds register PTP_CLOCK_HI resets after every second. The cn10k RPM block provides Rx/Tx timestamps to the NIX block using the new timestamp format. The software can read the current timestamp in nanoseconds by reading both PTP_CLOCK_SEC & PTP_CLOCK_HI registers. This patch provides support for new timestamp format. Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by: Rakesh Babu Saladi <rsaladi2@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21net: mdio-ipq4019: add delay after clock enableBaruch Siach1-1/+5
Experimentation shows that PHY detect might fail when the code attempts MDIO bus read immediately after clock enable. Add delay to stabilize the clock before bus access. PHY detect failure started to show after commit 7590fc6f80ac ("net: mdio: Demote probed message to debug print") that removed coincidental delay between clock enable and bus access. 10ms is meant to match the time it take to send the probed message over UART at 115200 bps. This might be a far overshoot. Fixes: 23a890d493e3 ("net: mdio: Add the reset function for IPQ MDIO driver") Signed-off-by: Baruch Siach <baruch.siach@siklu.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21bonding: add new option ns_ip6_targetHangbin Liu2-0/+131
This patch add a new bonding option ns_ip6_target, which correspond to the arp_ip_target. With this we set IPv6 targets and send IPv6 NS request to determine the health of the link. For other related options like the validation, we still use arp_validate, and will change to ns_validate later. Note: the sysfs configuration support was removed based on https://lore.kernel.org/netdev/8863.1645071997@famine Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21bonding: add new parameter ns_targetsHangbin Liu2-20/+219
Add a new bonding parameter ns_targets to store IPv6 address. Add required bond_ns_send/rcv functions first before adding IPv6 address option setting. Add two functions bond_send/rcv_validate so we can send/recv ARP and NS at the same time. Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21Bonding: split bond_handle_vlan from bond_arp_sendHangbin Liu1-24/+34
Function bond_handle_vlan() is split from bond_arp_send() for later IPv6 usage. Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21ravb: Use GFP_KERNEL instead of GFP_ATOMIC when possibleChristophe JAILLET1-1/+1
'max_rx_len' can be up to GBETH_RX_BUFF_MAX (i.e. 8192) (see 'gbeth_hw_info'). The default value of 'num_rx_ring' can be BE_RX_RING_SIZE (i.e. 1024). So this loop can allocate 8 Mo of memory. Previous memory allocations in this function already use GFP_KERNEL, so use __netdev_alloc_skb() and an explicit GFP_KERNEL instead of a implicit GFP_ATOMIC. This gives more opportunities of successful allocation. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21net: qualcomm: rmnet: Use skb_put_zero() to simplify codeChristophe JAILLET1-3/+1
Use skb_put_zero() instead of hand-writing it. This saves a few lines of code and is more readable. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21ath11k: Fix frames flush failure caused by deadlockBaochen Qiang1-1/+1
We are seeing below warnings: kernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0 kernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0 kernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0 this means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_work has no chance to run in 5 seconds. By setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasing ATH11K_FLUSH_TIMEOUT to 50 we get below warnings: kernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds. kernel: [ 120.763169] Not tainted 5.10.90 #12 kernel: [ 120.763177] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0 kernel: [ 120.763201] Call Trace: kernel: [ 120.763214] __schedule+0x785/0x12fa kernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bb kernel: [ 120.763242] schedule+0x7e/0xa1 kernel: [ 120.763253] schedule_timeout+0x98/0xfe kernel: [ 120.763266] ? run_local_timers+0x4a/0x4a kernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a] kernel: [ 120.763306] ? init_wait_entry+0x2e/0x2e kernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2 kernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763802] ? genl_rcv+0x36/0x36 kernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7 kernel: [ 120.763829] genl_rcv+0x28/0x36 kernel: [ 120.763840] netlink_unicast+0x179/0x24b kernel: [ 120.763854] netlink_sendmsg+0x393/0x401 kernel: [ 120.763872] sock_sendmsg+0x72/0x76 kernel: [ 120.763886] ____sys_sendmsg+0x170/0x1e6 kernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2 kernel: [ 120.763914] ___sys_sendmsg+0x95/0xd1 kernel: [ 120.763940] __sys_sendmsg+0x85/0xbf kernel: [ 120.763956] do_syscall_64+0x43/0x55 kernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9 kernel: [ 120.763977] RIP: 0033:0x79089f3fcc83 kernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002e kernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83 kernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009 kernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000 kernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980 kernel: [ 120.764032] R13: 00007ffe604f0638 R14: 000059b40e98c360 R15: 00007ffe604f0558 ... kernel: [ 120.765230] INFO: task kworker/u32:26:4239 blocked for more than 20 seconds. kernel: [ 120.765238] Not tainted 5.10.90 #12 kernel: [ 120.765245] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: [ 120.765253] task:kworker/u32:26 state:D stack: 0 pid: 4239 ppid: 2 flags:0x00004080 kernel: [ 120.765284] Workqueue: phy0 ieee80211_iface_work [mac80211] kernel: [ 120.765295] Call Trace: kernel: [ 120.765306] __schedule+0x785/0x12fa kernel: [ 120.765316] ? find_held_lock+0x3d/0xb2 kernel: [ 120.765331] schedule+0x7e/0xa1 kernel: [ 120.765340] schedule_preempt_disabled+0x15/0x1e kernel: [ 120.765349] __mutex_lock_common+0x561/0xc0d kernel: [ 120.765375] ? ieee80211_sta_work+0x3e/0x1232 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.765390] mutex_lock_nested+0x20/0x26 kernel: [ 120.765416] ieee80211_sta_work+0x3e/0x1232 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.765430] ? skb_dequeue+0x54/0x5e kernel: [ 120.765456] ? ieee80211_iface_work+0x7b/0x339 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.765485] process_one_work+0x270/0x504 kernel: [ 120.765501] worker_thread+0x215/0x376 kernel: [ 120.765514] kthread+0x159/0x168 kernel: [ 120.765526] ? pr_cont_work+0x5b/0x5b kernel: [ 120.765536] ? kthread_blkcg+0x31/0x31 kernel: [ 120.765550] ret_from_fork+0x22/0x30 ... kernel: [ 120.765867] Showing all locks held in the system: ... kernel: [ 120.766164] 5 locks held by wpa_supplicant/924: kernel: [ 120.766172] #0: ffffffffb1e63eb0 (cb_lock){++++}-{3:3}, at: genl_rcv+0x19/0x36 kernel: [ 120.766197] #1: ffffffffb1e5b1c8 (rtnl_mutex){+.+.}-{3:3}, at: nl80211_pre_doit+0x2a/0x15c [cfg80211] kernel: [ 120.766238] #2: ffff99f08347cd08 (&wdev->mtx){+.+.}-{3:3}, at: nl80211_deauthenticate+0xde/0x123 [cfg80211] kernel: [ 120.766279] #3: ffff99f09df12a48 (&local->mtx){+.+.}-{3:3}, at: ieee80211_destroy_auth_data+0x9b/0xe6 [mac80211] kernel: [ 120.766321] #4: ffff99f09df12ce0 (&local->chanctx_mtx){+.+.}-{3:3}, at: ieee80211_vif_release_channel+0x5e/0x81 [mac80211] ... kernel: [ 120.766585] 3 locks held by kworker/u32:26/4239: kernel: [ 120.766593] #0: ffff99f04458f948 ((wq_completion)phy0){+.+.}-{0:0}, at: process_one_work+0x19a/0x504 kernel: [ 120.766621] #1: ffffbad54b3cfe50 ((work_completion)(&sdata->work)){+.+.}-{0:0}, at: process_one_work+0x1c0/0x504 kernel: [ 120.766649] #2: ffff99f08347cd08 (&wdev->mtx){+.+.}-{3:3}, at: ieee80211_sta_work+0x3e/0x1232 [mac80211] With above info the issue is clear: First wmi_mgmt_tx_work is inserted to local->workqueue after sdata->work inserted, then wpa_supplicant acquires wdev->mtx in nl80211_deauthenticate and finally calls ath11k_mac_op_flush where it waits all mgmt. frames to be sent out by wmi_mgmt_tx_work. Meanwhile, sdata->work is blocked by wdev->mtx in ieee80211_sta_work, as a result wmi_mgmt_tx_work has no chance to run. Change to use ab->workqueue instead of local->workqueue to fix this issue. Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220217084545.18844-1-quic_bqiang@quicinc.com
2022-02-21ath11k: Handle failure in qmi firmware readySeevalamuthu Mariappan1-1/+5
In some scenarios like firmware crashes during init time and hardware gets restarted after qmi firmware ready event. During restart, ath11k_core_qmi_firmware_ready() returns timeout. But, this failure is not handled and ATH11K_FLAG_REGISTERED is set. When hardware restart completed, firmware sends firmware ready event again. Since ATH11K_FLAG_REGISTERED is already set, ath11k handles this as core restart. Inits are not done because of previous timeout. But ath11k_core_restart does deinit's which causes NULL pointer crash. Fix this by handling failure from ath11k_core_qmi_firmware_ready(). Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-00881-QCAHKSWPL_SILICONZ-1 Signed-off-by: Seevalamuthu Mariappan <quic_seevalam@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1645079195-13564-1-git-send-email-quic_seevalam@quicinc.com
2022-02-21ath11k: Invalidate cached reo ring entry before accessing itRameshkumar Sundaram1-1/+1
REO2SW ring descriptor is currently allocated in cacheable memory. While reaping reo ring entries on second trial after updating head pointer, first entry is not invalidated before accessing it. This results in host reaping and using cached descriptor which is already overwritten in memory by DMA device (HW). Since the contents of descriptor(buffer id, peer info and other information bits) are outdated host throws errors like below while parsing corresponding MSDU's and drops them. [347712.048904] ath11k_pci 0004:01:00.0: msdu_done bit in attention is not set [349173.355503] ath11k_pci 0004:01:00.0: frame rx with invalid buf_id 962 Move the try_again: label above ath11k_hal_srng_access_begin() so that first entry will be invalidated and prefetched. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Fixes: 6452f0a3d565 ("ath11k: allocate dst ring descriptors from cacheable memory") Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1645000354-32558-1-git-send-email-quic_ramess@quicinc.com
2022-02-21ath: Replace zero-length arrays with flexible-array membersGustavo A. R. Silva1-2/+2
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220216194915.GA904081@embeddedor
2022-02-21ath6kl: Replace zero-length arrays with flexible-array membersGustavo A. R. Silva1-13/+13
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220216194857.GA904059@embeddedor
2022-02-21ath11k: Replace zero-length arrays with flexible-array membersGustavo A. R. Silva5-11/+11
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220216194836.GA904035@embeddedor
2022-02-21ath10k: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220216194807.GA904008@embeddedor
2022-02-21ath9k: use hw_random API instead of directly dumping into random.cJason A. Donenfeld2-41/+32
Hardware random number generators are supposed to use the hw_random framework. This commit turns ath9k's kthread-based design into a proper hw_random driver. Cc: Toke Høiland-Jørgensen <toke@redhat.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: Rui Salvaterra <rsalvaterra@gmail.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Tested-by: Rui Salvaterra <rsalvaterra@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220216113323.53332-1-Jason@zx2c4.com
2022-02-21ath11k: configure RDDM size to mhi for recovery by firmwareWen Gong1-0/+2
The rddm_size is needed by firmware while mhi enter RDDM state, add it to support recovery when ath11k receive MHI_CB_EE_RDDM message. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220209060012.32478-4-quic_wgong@quicinc.com
2022-02-21ath11k: fix invalid m3 buffer addressCarl Huang1-0/+1
This is to fix m3 buffer reuse issue as m3_mem->size isn't set to ZERO in free function, which leads invalid m3 downloading to firmware and firmware crashed. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2 Signed-off-by: Carl Huang <quic_cjhuang@quicinc.com> Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220209060012.32478-3-quic_wgong@quicinc.com
2022-02-21ath11k: add ath11k_qmi_free_resource() for recoveryWen Gong2-0/+6
ath11k_qmi_free_target_mem_chunk() and ath11k_qmi_m3_free() is static in qmi.c, they are needed for recovery, export them in a new function. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220209060012.32478-2-quic_wgong@quicinc.com
2022-02-21rtw89: core.h: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220216195047.GA904198@embeddedor
2022-02-21brcmfmac: Replace zero-length arrays with flexible-array membersGustavo A. R. Silva2-2/+2
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220216194935.GA904103@embeddedor
2022-02-21rtw89: fix RCU usage in rtw89_core_txq_push()Jiri Kosina1-1/+4
ieee80211_tx_h_select_key() is performing a series of RCU dereferences, but rtw89_core_txq_push() is calling it (via ieee80211_tx_dequeue_ni()) without RCU read-side lock held; fix that. This addresses the splat below. ============================= WARNING: suspicious RCU usage 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G E ----------------------------- net/mac80211/tx.c:593 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by kworker/u33:0/184: #0: ffff9c0b14811d38 ((wq_completion)rtw89_tx_wq){+.+.}-{0:0}, at: process_one_work+0x258/0x660 #1: ffffb97380cf3e78 ((work_completion)(&rtwdev->txq_work)){+.+.}-{0:0}, at: process_one_work+0x258/0x660 stack backtrace: CPU: 8 PID: 184 Comm: kworker/u33:0 Tainted: G E 5.17.0-rc4-00003-gccad664b7f14 #3 473b49ab0e7c2d6af2900c756bfd04efd7a9de13 Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021 Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core] Call Trace: <TASK> dump_stack_lvl+0x58/0x71 ieee80211_tx_h_select_key+0x2c0/0x530 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea] process_one_work+0x2d8/0x660 worker_thread+0x39/0x3e0 ? process_one_work+0x660/0x660 kthread+0xe5/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> ============================= WARNING: suspicious RCU usage 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G E ----------------------------- net/mac80211/tx.c:607 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by kworker/u33:0/184: #0: ffff9c0b14811d38 ((wq_completion)rtw89_tx_wq){+.+.}-{0:0}, at: process_one_work+0x258/0x660 #1: ffffb97380cf3e78 ((work_completion)(&rtwdev->txq_work)){+.+.}-{0:0}, at: process_one_work+0x258/0x660 stack backtrace: CPU: 8 PID: 184 Comm: kworker/u33:0 Tainted: G E 5.17.0-rc4-00003-gccad664b7f14 #3 473b49ab0e7c2d6af2900c756bfd04efd7a9de13 Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021 Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core] Call Trace: <TASK> dump_stack_lvl+0x58/0x71 ieee80211_tx_h_select_key+0x464/0x530 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea] process_one_work+0x2d8/0x660 worker_thread+0x39/0x3e0 ? process_one_work+0x660/0x660 kthread+0xe5/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2202152037000.11721@cbobk.fhfr.pm
2022-02-21rtw88: coex: Update rtl8822c COEX version to 22020720Ching-Te Ku1-2/+2
Enable Wi-Fi/BT mailbox 0x45 handshake and Wi-Fi MIMO power save mechanism for Bluetooth gaming controller. BTCOEX Version: 22020720-2020 Desired_BT_Coex_Ver: 0x20 Desired_WL_FW_Ver: 9.9.11 Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220215004855.4098-7-pkshih@realtek.com
2022-02-21rtw88: coex: Add C2H/H2C handshake with BT mailbox for asking HID InfoChing-Te Ku6-11/+206
In order to recognize the gaming controller HID, make a C2H/H2C/Mailbox handshake to collect all the connected information from BT. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220215004855.4098-6-pkshih@realtek.com
2022-02-21rtw88: coex: Add WLAN MIMO power saving for Bluetooth gaming controllerChing-Te Ku7-11/+148
To keep high sensitivity reaction, Bluetooth gaming controller will send packet very frequently, it will make WLAN performance very poor. To solve this situation, MIMO PS mechanism makes WLAN/BT own an antenna itself, WLAN quits 2SS performance but it can get a stable 1SS performance and Bluetooth gaming controller can keep sensitivity reaction at the same time. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220215004855.4098-5-pkshih@realtek.com
2022-02-21rtw88: coex: update BT PTA counter regularlyChing-Te Ku3-12/+37
If BT PTA counter can not update regularly, it will lead coex mechanism run into some unexpected state. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220215004855.4098-4-pkshih@realtek.com
2022-02-21rtw88: coex: Improve WLAN throughput when HFP COEXChing-Te Ku1-7/+2
Disable power save TDMA mechanism under HFP COEX, so WLAN can TX/RX full time. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220215004855.4098-3-pkshih@realtek.com
2022-02-21rtw88: 8822ce: add support for TX/RX 1ss modeChin-Yen Lee5-4/+41
In some case, wifi chip need to be configed to be TX/RX 1ss mode. For this mode, wifi components, such as MAC/BB/RF, need to be specially set, and driver need to send SMPS action frame to inform AP. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220215004855.4098-2-pkshih@realtek.com
2022-02-20bnxt_en: Fix devlink fw_activateKalesh AP1-8/+31
To install a livepatch, first flash the package to NVM, and then activate the patch through the "HWRM_FW_LIVEPATCH" fw command. To uninstall a patch from NVM, flash the removal package and then activate it through the "HWRM_FW_LIVEPATCH" fw command. The "HWRM_FW_LIVEPATCH" fw command has to consider following scenarios: 1. no patch in NVM and no patch active. Do nothing. 2. patch in NVM, but not active. Activate the patch currently in NVM. 3. patch is not in NVM, but active. Deactivate the patch. 4. patch in NVM and the patch active. Do nothing. Fix the code to handle these scenarios during devlink "fw_activate". To install and activate a live patch: devlink dev flash pci/0000:c1:00.0 file thor_patch.pkg devlink -f dev reload pci/0000:c1:00.0 action fw_activate limit no_reset To remove and deactivate a live patch: devlink dev flash pci/0000:c1:00.0 file thor_patch_rem.pkg devlink -f dev reload pci/0000:c1:00.0 action fw_activate limit no_reset Fixes: 3c4153394e2c ("bnxt_en: implement firmware live patching") Reviewed-by: Vikas Gupta <vikas.gupta@broadcom.com> Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-20bnxt_en: Increase firmware message response DMA wait timeMichael Chan2-4/+10
When polling for the firmware message response, we first poll for the response message header. Once the valid length is detected in the header, we poll for the valid bit at the end of the message which signals DMA completion. Normally, this poll time for DMA completion is extremely short (0 to a few usec). But on some devices under some rare conditions, it can be up to about 20 msec. Increase this delay to 50 msec and use udelay() for the first 10 usec for the common case, and usleep_range() beyond that. Also, change the error message to include the above delay time when printing the timeout value. Fixes: 3c8c20db769c ("bnxt_en: move HWRM API implementation into separate file") Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-20bnxt_en: Restore the resets_reliable flag in bnxt_open()Kalesh AP1-2/+15
During ifdown, we call bnxt_inv_fw_health_reg() which will clear both the status_reliable and resets_reliable flags if these registers are mapped. This is correct because a FW reset during ifdown will clear these register mappings. If we detect that FW has gone through reset during the next ifup, we will remap these registers. But during normal ifup with no FW reset, we need to restore the resets_reliable flag otherwise we will not show the reset counter during devlink diagnose. Fixes: 8cc95ceb7087 ("bnxt_en: improve fw diagnose devlink health messages") Reviewed-by: Vikas Gupta <vikas.gupta@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-20bnxt_en: Fix incorrect multicast rx mask setting when not requestedPavan Chebbi1-5/+8
We should setup multicast only when net_device flags explicitly has IFF_MULTICAST set. Otherwise we will incorrectly turn it on even when not asked. Fix it by only passing the multicast table to the firmware if IFF_MULTICAST is set. Fixes: 7d2837dd7a32 ("bnxt_en: Setup multicast properly after resetting device.") Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-20bnxt_en: Fix occasional ethtool -t loopback test failuresMichael Chan3-1/+9
In the current code, we setup the port to PHY or MAC loopback mode and then transmit a test broadcast packet for the loopback test. This scheme fails sometime if the port is shared with management firmware that can also send packets. The driver may receive the management firmware's packet and the test will fail when the contents don't match the test packet. Change the test packet to use it's own MAC address as the destination and setup the port to only receive it's own MAC address. This should filter out other packets sent by management firmware. Fixes: 91725d89b97a ("bnxt_en: Add PHY loopback to ethtool self-test.") Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-20bnxt_en: Fix offline ethtool selftest with RDMA enabledMichael Chan2-8/+14
For offline (destructive) self tests, we need to stop the RDMA driver first. Otherwise, the RDMA driver will run into unrecoverable errors when destructive firmware tests are being performed. The irq_re_init parameter used in the half close and half open sequence when preparing the NIC for offline tests should be set to true because the RDMA driver will free all IRQs before the offline tests begin. Fixes: 55fd0cf320c3 ("bnxt_en: Add external loopback test to ethtool selftest.") Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Ben Li <ben.li@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-20bnxt_en: Fix active FEC reporting to ethtoolSomnath Kotur1-0/+3
ethtool --show-fec <interface> does not show anything when the Active FEC setting in the chip is set to None. Fix it to properly return ETHTOOL_FEC_OFF in that case. Fixes: 8b2775890ad8 ("bnxt_en: Report FEC settings to ethtool.") Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: prestera: acl: fix 'client_map' buff overflowVolodymyr Mytnyk1-1/+1
smatch warnings: drivers/net/ethernet/marvell/prestera/prestera_acl.c:103 prestera_acl_chain_to_client() error: buffer overflow 'client_map' 3 <= 3 prestera_acl_chain_to_client(u32 chain_index, ...) ... u32 client_map[] = { PRESTERA_HW_COUNTER_CLIENT_LOOKUP_0, PRESTERA_HW_COUNTER_CLIENT_LOOKUP_1, PRESTERA_HW_COUNTER_CLIENT_LOOKUP_2 }; if (chain_index > ARRAY_SIZE(client_map)) ... Fixes: fa5d824ce5dd ("net: prestera: acl: add multi-chain support offload") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: dsa: microchip: add ksz8563 to ksz9477 I2C driverAhmad Fatoum1-0/+1
The KSZ9477 SPI driver already has support for the KSZ8563. The same switch chip can also be managed via i2c and we have an KSZ9477 I2C driver, but that one lacks the relevant compatible entry. Add it. DT bindings already describe this compatible. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: dsa: microchip: ksz9477: export HW stats over stats64 interfaceOleksij Rempel3-0/+104
Provide access to HW offloaded packets over stats64 interface. The rx/tx_bytes values needed some fixing since HW is accounting size of the Ethernet frame together with FCS. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: phylink: remove phylink_config's pcs_pollRussell King (Oracle)1-2/+1
phylink_config's pcs_poll is no longer used, let's get rid of it. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19dpaa2-eth: Update SINGLE_STEP register accessRadu Bulie2-10/+93
DPAA2 MAC supports 1588 one step timestamping. If this option is enabled then for each transmitted PTP event packet, the 1588 SINGLE_STEP register is accessed to modify the following fields: -offset of the correction field inside the PTP packet -UDP checksum update bit, in case the PTP event packet has UDP encapsulation These values can change any time, because there may be multiple PTP clients connected, that receive various 1588 frame types: - L2 only frame - UDP / Ipv4 - UDP / Ipv6 - other The current implementation uses dpni_set_single_step_cfg to update the SINLGE_STEP register. Using an MC command on the Tx datapath for each transmitted 1588 message introduces high delays, leading to low throughput and consequently to a small number of supported PTP clients. Besides these, the nanosecond correction field from the PTP packet will contain the high delay from the driver which together with the originTimestamp will render timestamp values that are unacceptable in a GM clock implementation. This patch updates the Tx datapath for 1588 messages when single step timestamp is enabled and provides direct access to SINGLE_STEP register, eliminating the overhead caused by the dpni_set_single_step_cfg MC command. MC version >= 10.32 implements this functionality. If the MC version does not have support for returning the single step register base address, the driver will use dpni_set_single_step_cfg command for updates operations. All the delay introduced by dpni_set_single_step_cfg function will be eliminated (if MC version has support for returning the base address of the single step register), improving the egress driver performance for PTP packets when single step timestamping is enabled. Before these changes the maximum throughput for 1588 messages with single step hardware timestamp enabled was around 2000pps. After the updates the throughput increased up to 32.82 Mbps / 46631.02 pps. Signed-off-by: Radu Bulie <radu-andrei.bulie@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19dpaa2-eth: Update dpni_get_single_step_cfg commandRadu Bulie3-1/+13
dpni_get_single_step_cfg is an MC firmware command used for retrieving the contents of SINGLE_STEP 1588 register available in a DPMAC. This patch adds a new version of this command that returns as an extra argument the physical base address of the aforementioned register. The address will be used to directly modify the contents of the SINGLE_STEP register instead of invoking the MC command dpni_set_single_step_cgf. The former approach introduced huge delays on the TX datapath when one step PTP events were transmitted. This led to low throughput and high latencies observed in the PTP correction field. Signed-off-by: Radu Bulie <radu-andrei.bulie@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: dsa: microchip: fix bridging with more than two member portsSvenning Sørensen1-3/+23
Commit b3612ccdf284 ("net: dsa: microchip: implement multi-bridge support") plugged a packet leak between ports that were members of different bridges. Unfortunately, this broke another use case, namely that of more than two ports that are members of the same bridge. After that commit, when a port is added to a bridge, hardware bridging between other member ports of that bridge will be cleared, preventing packet exchange between them. Fix by ensuring that the Port VLAN Membership bitmap includes any existing ports in the bridge, not just the port being added. Fixes: b3612ccdf284 ("net: dsa: microchip: implement multi-bridge support") Signed-off-by: Svenning Sørensen <sss@secomea.com> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: prestera: flower: fix destroy tmpl in chainVolodymyr Mytnyk1-9/+19
Fix flower destroy template callback to release template only for specific tc chain instead of all chain tempaltes. The issue was intruduced by previous commit that introduced multi-chain support. Fixes: fa5d824ce5dd ("net: prestera: acl: add multi-chain support offload") Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.