- 22 Dec, 2022 1 commit
-
-
Yang Yingliang authored
It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called to free and drop the SKB when it's reset, so replace it with dev_kfree_skb_irq(). Compile tested only. Fixes: 43f66a6c ("Add ipw2200 wireless driver.") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221208143826.2385218-1-yangyingliang@huawei.com
-
- 21 Dec, 2022 17 commits
-
-
Jun ASAKA authored
Fixing transmission failure which results in "authentication with ... timed out". This can be fixed by disable the REG_TXPAUSE. Signed-off-by:
Jun ASAKA <JunASAKA@zzy040330.moe> Reviewed-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Bitterblue Smith authored
Copied from the newer vendor driver, v5.2.2.4. Signed-off-by:
Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by:
-
Jes Sorensen authored
This chip is found in cheap USB devices from TP-Link, D-Link, etc. Features: 2.4 GHz, b/g/n mode, 1T1R, 150 Mbps. Chip versions older than "I cut" need software rate control. That will be in the next commit. Until then MCS7 is used for all data frames. The "I cut" chips are not supported. They require different firmware and initialisation tables. Support can be added if someone has the hardware to test it. Co-developed-by:
Andrea Merello <andrea.merello@gmail.com> Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Signed-off-by:
Jes Sorensen <Jes.Sorensen@gmail.com> Co-developed-by:
-
Bitterblue Smith authored
Define the constants CCK_AGC_RPT_LNA_IDX_MASK and CCK_AGC_RPT_VGA_IDX_MASK instead of using the same literals in four places. And get the bits from cck_agc_rpt using u8_get_bits(). It's a cosmetic change only. Signed-off-by:
-
Bitterblue Smith authored
And pass const char* to it. Signed-off-by:
-
Bitterblue Smith authored
Every chip family except RTL8723AU has a copy of the efuse dumping code. Remove this and dump the efuse from a single place using a new function rtl8xxxu_dump_efuse(). Also, use print_hex_dump() to print the efuse instead of a loop and dev_info(). It shows the ASCII interpretation of the bytes, which is nice. Signed-off-by:
-
Chih-Kang Chang authored
Some hardware modules don't have good RF characteristic as regular. It could have RF PA characteristic that current code doesn't handle properly, and it runs into wrong DPK flow that doesn't complete DPK resulting in bad EVM. Signed-off-by:
Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by:
-
Po-Hao Huang authored
Reduce dwell time to improve scan duration in 6 GHz. This is required for scan requests that does not include RNR parsing and does full channel scan. Signed-off-by:
Po-Hao Huang <phhuang@realtek.com> Signed-off-by:
-
Eric Huang authored
BSS color mapping register is different per IC, therefore, move this register to chip_info and update the setting function. Without this patch, wrong BSS color causes behavior abnormal, especially DL-OFDMA. Signed-off-by:
Eric Huang <echuang@realtek.com> Signed-off-by:
-
Ching-Te Ku authored
In order to make different version of TDMA and coming update in the future can all work well, use BTC format version to replace chip_id, because format could change for specific chip_id. Signed-off-by:
Ching-Te Ku <ku920601@realtek.com> Signed-off-by:
-
Ching-Te Ku authored
Change the checking logic to switch case. Make the code more readable. There are more feature including to common code, in order to commit the following version of the features, switch case will make the logic more clearly. This patch did not change logic. Signed-off-by:
-
Ching-Te Ku authored
Wi-Fi firmware update AFH report feature to version 2. If there is BT BLE device connect to DUT, the mechanism will send H2C to request BT BLE channel map, it will help to debug. Signed-off-by:
-
Ching-Te Ku authored
The different version use different bit definition to enable firmware report. WiFi firmware will report information from Bluetooth firmware or some Wi-Fi firmware mechanism/status to driver by these bits. To solve the difference, add a function to map bitmap and versions. Signed-off-by:
-
Ching-Te Ku authored
Ask WiFi firmware to send Bluetooth version report when we want to show Bluetooth debug info. If there is no request for debug log, driver will not enable the report. This modification can save some C2H/H2C resources. Signed-off-by:
-
Ping-Ke Shih authored
Previous patch has added format version derived from firmware version. Use the format version, and remove constant version number from chip_info. Signed-off-by:
-
Ping-Ke Shih authored
Originally, each chip maintains its own format version followed firmware it uses. As new chip is added, firmware changes format of exchange messages to have rich information to handle more conditions. When old chip is going to upgrade firmware, it could use new format and driver needs to maintain compatibility with old firmware. So, add this version array to achieve this goal. Signed-off-by:
-
https://github.com/nbd168/wirelessKalle Valo authored
mt76 patches for 6.2 - fixes - per-PHY LED support
-
- 14 Dec, 2022 15 commits
-
-
Li Zetao authored
There is a global-out-of-bounds reported by KASAN: BUG: KASAN: global-out-of-bounds in _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411 CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D 6.1.0-rc8+ #144 e15588508517267d37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), Call Trace: <TASK> ... kasan_report+0xbb/0x1c0 _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae] rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae] ... </TASK> The root cause of the problem is that the comparison order of "prate_section" in _rtl8812ae_phy_set_txpower_limit() is wrong. The _rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two strings from tail to head, which causes the problem. In the _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet this requirement by carefully designing the comparison order. For example, "pregulation" and "pbandwidth" are compared in order of length from small to large, first is 3 and last is 4. However, the comparison order of "prate_section" dose not obey such order requirement, therefore when "prate_section" is "HT", when comparing from tail to head, it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As mentioned above, the _rtl8812ae_eq_n_byte() has the same function as strcmp(), so just strcmp() is enough. Fix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely. Although it can be fixed by adjusting the comparison order of "prate_section", this may cause the value of "rate_section" to not be from 0 to 5. In addition, commit "21e4b072" not only moved driver from staging to regular tree, but also added setting txpower limit function during the driver config phase, so the problem was introduced by this commit. Fixes: 21e4b072 ("rtlwifi: rtl8821ae: Move driver from staging to regular tree") Signed-off-by:
Li Zetao <lizetao1@huawei.com> Acked-by:
-
Ping-Ke Shih authored
RX DCK stands for RX DC calibration that affects CCA, so abnormal calibration values resulted from calibration failure can cause TX get stuck. To solve this, redo calibration if result is bad (over thresholds). When retry count is over, do recovery that sets high gain fields of RX DCK results from low gain fields. Signed-off-by:
-
Ping-Ke Shih authored
Some DPK settings are wrong, and causes bad TX performance occasionally. So, fix them by internal suggestions. Fixes: da4cea16 ("rtw89: 8852c: rfk: add DPK") Signed-off-by:
-
Ping-Ke Shih authored
After filling calibration parameters, set BIT(0) to enable the hardware circuit, but original set incorrect bit that affects a little TX performance. Fixes: 76599a8d ("rtw89: 8852c: rfk: add DACK") Signed-off-by:
-
Ping-Ke Shih authored
Normally, system image should ensure firmware integrity, but we provide an advance feature to ensure this by security section along with firmware. To enable this feature, custom ID is programmed into efuse, and driver will download proper security section to firmware. Since I don't have this kind hardware modules on hand yet, but new format is used by newer firmware. Therefore, I prepare this patch in advance to consider size of security section as a factor of checking rule of firmware size, but don't actually download security section to firmware. This patch is backward compatible, so it will be safe to have this change before adding an new format firmware to linux-firmware repository. Signed-off-by:
-
Ping-Ke Shih authored
ER (Extended Range) SU is to have a larger coverage. We set this as a RA capability, and then firmware can choose ER SU to transmit packets to reception at cell edge. For 8852C, it needs to fill this capability in TXWD, so update rtw89_build_txwd_info0_v1(). Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called to free and drop the SKB when it's shutdown, so replace it with dev_kfree_skb_irq(). Compile tested only. Fixes: 26f1fad2 ("New driver: rtl8xxxu (mac80211)") Signed-off-by:
-
Bitterblue Smith authored
Just because priv->cck_agc_report_type is only one bit doesn't mean it works like a bool. The value assigned to it loses all bits except bit 0, so only assign 0 or 1 to it. This affects the RTL8192EU, but rtl8xxxu already can't connect to any networks with this chip, so it probably didn't bother anyone. Fixes: 2ad2a813 ("wifi: rtl8xxxu: Fix the CCK RSSI calculation") Signed-off-by:
-
Bitterblue Smith authored
Just because priv->pi_enabled is only one bit doesn't mean it works like a bool. The value assigned to it loses all bits except bit 0, so only assign 0 or 1 to it. This affects the RTL8188FU, but fixing the assignment didn't make a difference for my device. Fixes: c888183b ("wifi: rtl8xxxu: Support new chip RTL8188FU") Signed-off-by:
-
Zhengchao Shao authored
When kfifo_alloc() failed in lbs_init_adapter(), cmd buffer is not released. Add free memory to processing error path. Fixes: 7919b89c ("libertas: convert libertas driver to use an event/cmdresp queue") Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call consume_skb() from hardware interrupt context or with interrupts being disabled. So replace dev_kfree_skb() with dev_consume_skb_irq() under spin_lock_irqsave(). Compile tested only. Fixes: 4bc85c13 ("Revert "iwlwifi: split the drivers for agn and legacy devices 3945/4965"") Signed-off-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. All the SKBs have been dequeued from the old queue, so it's safe to enqueue these SKBs to a free queue, then free them after spin_unlock_irqrestore() at once. Compile tested only. Fixes: 5c99f04f ("rtlwifi: rtl8723be: Update driver to match Realtek release of 06/28/14") Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. All the SKBs have been dequeued from the old queue, so it's safe to enqueue these SKBs to a free queue, then free them after spin_unlock_irqrestore() at once. Compile tested only. Fixes: 7fe3b3ab ("rtlwifi: rtl8188ee: rtl8821ae: Fix a queue locking problem") Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. All the SKBs have been dequeued from the old queue, so it's safe to enqueue these SKBs to a free queue, then free them after spin_unlock_irqrestore() at once. Compile tested only. Fixes: 5c99f04f ("rtlwifi: rtl8723be: Update driver to match Realtek release of 06/28/14") Signed-off-by:
-
Yuan Can authored
The coex_cb needs to be freed when rsi_create_kthread() failed in rsi_coex_attach(). Fixes: 2108df3c ("rsi: add coex support") Signed-off-by:
Yuan Can <yuancan@huawei.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
- 13 Dec, 2022 1 commit
-
-
Christophe JAILLET authored
vcap_alloc_rule() can't return NULL. So remove some dead-code Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/27992ffcee47fc865ce87274d6dfcffe7a1e69e0.1670873784.git.christophe.jaillet@wanadoo.frSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- 12 Dec, 2022 6 commits
-
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: enable IPA v4.7 support The first patch in this series adds "qcom,sm6350-ipa" as a possible IPA compatible string, for the Qualcomm SM6350 SoC. That SoC uses IPA v4.7 The second patch in this series adds code that enables support for IPA v4.7. DTS updates that make use of these will be merged later. ==================== Link: https://lore.kernel.org/r/20221208211529.757669-1-elder@linaro.orgSigned-off-by:
-
Alex Elder authored
Add the necessary register and data definitions needed for IPA v4.7, which is found on the SM6350 SoC. Co-developed-by:
Luca Weiss <luca.weiss@fairphone.com> Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Luca Weiss authored
Add support for SM6350, which uses IPA v4.7. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Coco Li authored
Eric Dumazet implemented Big TCP that allowed bigger TSO/GRO packet sizes for IPv6 traffic. See patch series: 'commit 89527be8 ("net: add IFLA_TSO_{MAX_SIZE|SEGS} attributes")' This reduces the number of packets traversing the networking stack and should usually improves performance. However, it also inserts a temporary Hop-by-hop IPv6 extension header. Using the HBH header removal method in the previous patch, the extra header be removed in bnxt drivers to allow it to send big TCP packets (bigger TSO packets) as well. Tested: Compiled locally To further test functional correctness, update the GSO/GRO limit on the physical NIC: ip link set eth0 gso_max_size 181000 ip link set eth0 gro_max_size 181000 Note that if there are bonding or ipvan devices on top of the physical NIC, their GSO sizes need to be updated as well. Then, IPv6/TCP packets with sizes larger than 64k can be observed. Signed-off-by:
Coco Li <lixiaoyan@google.com> Reviewed-by:
Michael Chan <michael.chan@broadcom.com> Tested-by:
-
Coco Li authored
IPv6/TCP and GRO stacks can build big TCP packets with an added temporary Hop By Hop header. Is GSO is not involved, then the temporary header needs to be removed in the driver. This patch provides a generic helper for drivers that need to modify their headers in place. Tested: Compiled and ran with ethtool -K eth1 tso off Could send Big TCP packets Signed-off-by:
-
Jakub Kicinski authored
Ido Schimmel says: ==================== bridge: mcast: Extensions for EVPN tl;dr ===== This patchset creates feature parity between user space and the kernel and allows the former to install and replace MDB port group entries with a source list and associated filter mode. This is required for EVPN use cases where multicast state is not derived from snooped IGMP/MLD packets, but instead derived from EVPN routes exchanged by the control plane in user space. Background ========== IGMPv3 [1] and MLDv2 [2] differ from earlier versions of the protocols in that they add support for source-specific multicast. That is, hosts can advertise interest in listening to a particular multicast address only from specific source addresses or from all sources except for specific source addresses. In kernel 5.10 [3][4], the bridge driver gained the ability to snoop IGMPv3/MLDv2 packets and install corresponding MDB port group entries. For example, a snooped IGMPv3 Membership Report that contains a single MODE_IS_EXCLUDE record for group 239.10.10.10 with sources 192.0.2.1, 192.0.2.2, 192.0.2.20 and 192.0.2.21 would trigger the creation of these entries: # bridge -d mdb show dev br0 port veth1 grp 239.10.10.10 src 192.0.2.21 temp filter_mode include proto kernel blocked dev br0 port veth1 grp 239.10.10.10 src 192.0.2.20 temp filter_mode include proto kernel blocked dev br0 port veth1 grp 239.10.10.10 src 192.0.2.2 temp filter_mode include proto kernel blocked dev br0 port veth1 grp 239.10.10.10 src 192.0.2.1 temp filter_mode include proto kernel blocked dev br0 port veth1 grp 239.10.10.10 temp filter_mode exclude source_list 192.0.2.21/0.00,192.0.2.20/0.00,192.0.2.2/0.00,192.0.2.1/0.00 proto kernel While the kernel can install and replace entries with a filter mode and source list, user space cannot. It can only add EXCLUDE entries with an empty source list, which is sufficient for IGMPv2/MLDv1, but not for IGMPv3/MLDv2. Use cases where the multicast state is not derived from snooped packets, but instead derived from routes exchanged by the user space control plane require feature parity between user space and the kernel in terms of MDB configuration. Such a use case is detailed in the next section. Motivation ========== RFC 7432 [5] defines a "MAC/IP Advertisement route" (type 2) [6] that allows NVE switches in the EVPN network to advertise and learn reachability information for unicast MAC addresses. Traffic destined to a unicast MAC address can therefore be selectively forwarded to a single NVE switch behind which the MAC is located. The same is not true for IP multicast traffic. Such traffic is simply flooded as BUM to all NVE switches in the broadcast domain (BD), regardless if a switch has interested receivers for the multicast stream or not. This is especially problematic for overlay networks that make heavy use of multicast. The issue is addressed by RFC 9251 [7] that defines a "Selective Multicast Ethernet Tag Route" (type 6) [8] which allows NVE switches in the EVPN network to advertise multicast streams that they are interested in. This is done by having each switch suppress IGMP/MLD packets from being transmitted to the NVE network and instead communicate the information over BGP to other switches. As far as the bridge driver is concerned, the above means that the multicast state (i.e., {multicast address, group timer, filter-mode, (source records)}) for the VXLAN bridge port is not populated by the kernel from snooped IGMP/MLD packets (they are suppressed), but instead by user space. Specifically, by the routing daemon that is exchanging EVPN routes with other NVE switches. Changes are obviously also required in the VXLAN driver, but they are the subject of future patchsets. See the "Future work" section. Implementation ============== The user interface is extended to allow user space to specify the filter mode of the MDB port group entry and its source list. Replace support is also added so that user space would not need to remove an entry and re-add it only to edit its source list or filter mode, as that would result in packet loss. Example usage: # bridge mdb replace dev br0 port dummy10 grp 239.1.1.1 permanent \ source_list 192.0.2.1,192.0.2.3 filter_mode exclude proto zebra # bridge -d -s mdb show dev br0 port dummy10 grp 239.1.1.1 src 192.0.2.3 permanent filter_mode include proto zebra blocked 0.00 dev br0 port dummy10 grp 239.1.1.1 src 192.0.2.1 permanent filter_mode include proto zebra blocked 0.00 dev br0 port dummy10 grp 239.1.1.1 permanent filter_mode exclude source_list 192.0.2.3/0.00,192.0.2.1/0.00 proto zebra 0.00 The netlink interface is extended with a few new attributes in the RTM_NEWMDB request message: [ struct nlmsghdr ] [ struct br_port_msg ] [ MDBA_SET_ENTRY ] struct br_mdb_entry [ MDBA_SET_ENTRY_ATTRS ] [ MDBE_ATTR_SOURCE ] struct in_addr / struct in6_addr [ MDBE_ATTR_SRC_LIST ] // new [ MDBE_SRC_LIST_ENTRY ] [ MDBE_SRCATTR_ADDRESS ] struct in_addr / struct in6_addr [ ...] [ MDBE_ATTR_GROUP_MODE ] // new u8 [ MDBE_ATTR_RTPORT ] // new u8 No changes are required in RTM_NEWMDB responses and notifications, as all the information can already be dumped by the kernel today. Testing ======= Tested with existing bridge multicast selftests: bridge_igmp.sh, bridge_mdb_port_down.sh, bridge_mdb.sh, bridge_mld.sh, bridge_vlan_mcast.sh. In addition, added many new test cases for existing as well as for new MDB functionality. Patchset overview ================= Patches #1-#8 are non-functional preparations for the core changes in later patches. Patches #9-#10 allow user space to install (*, G) entries with a source list and associated filter mode. Specifically, patch #9 adds the necessary kernel plumbing and patch #10 exposes the new functionality to user space via a few new attributes. Patch #11 allows user space to specify the routing protocol of new MDB port group entries so that a routing daemon could differentiate between entries installed by it and those installed by an administrator. Patch #12 allows user space to replace MDB port group entries. This is useful, for example, when user space wants to add a new source to a source list. Instead of deleting a (*, G) entry and re-adding it with an extended source list (which would result in packet loss), user space can simply replace the current entry. Patches #13-#14 add tests for existing MDB functionality as well as for all new functionality added in this patchset. Future work =========== The VXLAN driver will need to be extended with an MDB so that it could selectively forward IP multicast traffic to NVE switches with interested receivers instead of simply flooding it to all switches as BUM. The idea is to reuse the existing MDB interface for the VXLAN driver in a similar way to how the FDB interface is shared between the bridge and VXLAN drivers. From command line perspective, configuration will look as follows: # bridge mdb add dev br0 port vxlan0 grp 239.1.1.1 permanent \ filter_mode exclude source_list 198.50.100.1,198.50.100.2 # bridge mdb add dev vxlan0 port vxlan0 grp 239.1.1.1 permanent \ filter_mode include source_list 198.50.100.3,198.50.100.4 \ dst 192.0.2.1 dst_port 4789 src_vni 2 # bridge mdb add dev vxlan0 port vxlan0 grp 239.1.1.1 permanent \ filter_mode exclude source_list 198.50.100.1,198.50.100.2 \ dst 192.0.2.2 dst_port 4789 src_vni 2 Where the first command is enabled by this set, but the next two will be the subject of future work. From netlink perspective, the existing PF_BRIDGE/RTM_*MDB messages will be extended to the VXLAN driver. This means that a few new attributes will be added (e.g., 'MDBE_ATTR_SRC_VNI') and that the handlers for these messages will need to move to net/core/rtnetlink.c. The rtnetlink code will call into the appropriate driver based on the ifindex specified in the ancillary header. iproute2 patches can be found here [9]. Changelog ========= Since v1 [10]: * Patch #12: Remove extack from br_mdb_replace_group_sg(). * Patch #12: Change 'nlflags' to u16 and move it after 'filter_mode' to pack the structure. Since RFC [11]: * Patch #6: New patch. * Patch #9: Use an array instead of a list to store source entries. * Patch #10: Use an array instead of list to store source entries. * Patch #10: Drop br_mdb_config_attrs_fini(). * Patch #11: Reject protocol for host entries. * Patch #13: New patch. * Patch #14: New patch. [1] https://datatracker.ietf.org/doc/html/rfc3376 [2] https://www.rfc-editor.org/rfc/rfc3810 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6af52ae2ed14a6bc756d5606b29097dfd76740b8 [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68d4fd30c83b1b208e08c954cd45e6474b148c87 [5] https://datatracker.ietf.org/doc/html/rfc7432 [6] https://datatracker.ietf.org/doc/html/rfc7432#section-7.2 [7] https://datatracker.ietf.org/doc/html/rfc9251 [8] https://datatracker.ietf.org/doc/html/rfc9251#section-9.1 [9] https://github.com/idosch/iproute2/commits/submit/mdb_v1 [10] https://lore.kernel.org/netdev/20221208152839.1016350-1-idosch@nvidia.com/ [11] https://lore.kernel.org/netdev/20221018120420.561846-1-idosch@nvidia.com/ ==================== Link: https://lore.kernel.org/r/20221210145633.1328511-1-idosch@nvidia.comSigned-off-by:
-
