- 15 Apr, 2024 26 commits
-
-
Jakub Kicinski authored
Developing Python tests is a bit annoying because when test fails we only print the fail message and no info about which exact check led to it. Print the location (the first line of this example is new): # At /root/ksft-net-drv/./net/nl_netdev.py line 38: # Check failed 0 != 10 not ok 3 nl_netdev.page_pool_check Reviewed-by:
Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/20240412141436.828666-4-kuba@kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
YNL currently reports None for empty dump: $ cli.py ...netdev.yaml --dump page-pool-get None This doesn't matter for the CLI but when writing YNL based tests having to deal with either list or None is annoying. Limit the None conversion to non-dump ops: $ cli.py ...netdev.yaml --dump page-pool-get [] Reviewed-by:
Donald Hunter <donald.hunter@gmail.com> Link: https://lore.kernel.org/r/20240412141436.828666-3-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Add very basic page pool use so that we can exercise the netlink uAPI in a selftest. Page pool gets created on open, destroyed on close. But we control allocating of a single page thru debugfs. This page may survive past the page pool itself so that we can test orphaned page pools. Link: https://lore.kernel.org/r/20240412141436.828666-2-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Breno Leitao says: ==================== net: dqs: optimize if stall threshold is not set Here are four patches aimed at enhancing the Dynamic Queue Limit (DQL) subsystem within the networking stack. The first two commits involve code refactoring, while the third patch introduces the actual change. The fourth patch just improves the cache locality. Typically, when DQL is enabled, stall information is always populated through dql_queue_stall(). However, this information is only necessary if a stall threshold is set, which is stored in struct dql->stall_thrs. Although dql_queue_stall() is relatively inexpensive, it is not entirely free due to memory barriers and similar overheads. To optimize performance, refrain from calling dql_queue_stall() when no stall threshold is set, thus avoiding the processing of unnecessary information. v1: https://lore.kernel.org/all/20240404145939.3601097-1-leitao@debian.org/ ==================== Link: https://lore.kernel.org/r/20240411192241.2498631-1-leitao@debian.orgSigned-off-by:
-
Breno Leitao authored
With the previous change, struct dqs->stall_thrs will be in the hot path (at queue side), even if DQS is disabled. The other fields accessed in this function (last_obj_cnt and num_queued) are in the first cache line, let's move this field (stall_thrs) to the very first cache line, since there is a hole there. This does not change the structure size, since it moves an short (2 bytes) to 4-bytes whole in the first cache line. This is the new structure format now: struct dql { unsigned int num_queued; unsigned int last_obj_cnt; ... short unsigned int stall_thrs; /* XXX 2 bytes hole, try to pack */ ... /* --- cacheline 1 boundary (64 bytes) --- */ ... /* Longest stall detected, reported to user */ short unsigned int stall_max; /* XXX 2 bytes hole, try to pack */ }; Also, read the stall_thrs (now in the very first cache line) earlier, together with dql->num_queued (also in the first cache line). Suggested-by:Eric Dumazet <edumazet@google.com> Signed-off-by:
Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20240411192241.2498631-5-leitao@debian.orgSigned-off-by:
-
Breno Leitao authored
When Dynamic Queue Limit (DQL) is set, it always populate stall information through dql_queue_stall(). However, this information is only necessary if a stall threshold is set, stored in struct dql->stall_thrs. dql_queue_stall() is cheap, but not free, since it does have memory barriers and so forth. Do not call dql_queue_stall() if there is no stall threshold set, and save some CPU cycles. Signed-off-by:
-
Breno Leitao authored
The dql_queued() function currently handles both queuing object counts and populating bitmaps for reporting stalls. This commit splits the bitmap population into a separate function, allowing for conditional invocation in scenarios where the feature is disabled. This refactor maintains functionality while improving code organization. Signed-off-by:
-
Breno Leitao authored
If the dql_queued() function receives an invalid argument, WARN about it and continue, instead of crashing the kernel. This was raised by checkpatch, when I am refactoring this code (see following patch/commit) WARNING: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants Signed-off-by:
-
David S. Miller authored
Julien Panis says: ==================== Add minimal XDP support to TI AM65 CPSW Ethernet driver This patch adds XDP support to TI AM65 CPSW Ethernet driver. The following features are implemented: NETDEV_XDP_ACT_BASIC, NETDEV_XDP_ACT_REDIRECT, and NETDEV_XDP_ACT_NDO_XMIT. Zero-copy and non-linear XDP buffer supports are NOT implemented. Besides, the page pool memory model is used to get better performance. ==================== Signed-off-by:Julien Panis <jpanis@baylibre.com>
-
Julien Panis authored
This patch adds XDP (eXpress Data Path) support to TI AM65 CPSW Ethernet driver. The following features are implemented: - NETDEV_XDP_ACT_BASIC (XDP_PASS, XDP_TX, XDP_DROP, XDP_ABORTED) - NETDEV_XDP_ACT_REDIRECT (XDP_REDIRECT) - NETDEV_XDP_ACT_NDO_XMIT (ndo_xdp_xmit callback) The page pool memory model is used to get better performance. Below are benchmark results obtained for the receiver with iperf3 default parameters: - Without page pool: 495 Mbits/sec - With page pool: 605 Mbits/sec (actually 610 Mbits/sec, with a 5 Mbits/sec loss due to extra processing in the hot path to handle XDP). Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Julien Panis authored
This patch introduces a member and the related accessors which can be used to store descriptor specific additional information. This member can store, for instance, an ID to differentiate a skb TX buffer type from a xdpf TX buffer type. Signed-off-by:
-
Julien Panis authored
This patch adds accessors for desc_size and cpumem members. They may be used, for instance, to compute a descriptor index. Reviewed-by:
-
Gabriel Krisman Bertazi authored
We've observed a 7-12% performance regression in iperf3 UDP ipv4 and ipv6 tests with multiple sockets on Zen3 cpus, which we traced back to commit f0ea27e7 ("udp: re-score reuseport groups when connected sockets are present"). The failing tests were those that would spawn UDP sockets per-cpu on systems that have a high number of cpus. Unsurprisingly, it is not caused by the extra re-scoring of the reused socket, but due to the compiler no longer inlining compute_score, once it has the extra call site in udp4_lib_lookup2. This is augmented by the "Safe RET" mitigation for SRSO, needed in our Zen3 cpus. We could just explicitly inline it, but compute_score() is quite a large function, around 300b. Inlining in two sites would almost double udp4_lib_lookup2, which is a silly thing to do just to workaround a mitigation. Instead, this patch shuffles the code a bit to avoid the multiple calls to compute_score. Since it is a static function used in one spot, the compiler can safely fold it in, as it did before, without increasing the text size. With this patch applied I ran my original iperf3 testcases. The failing cases all looked like this (ipv4): iperf3 -c 127.0.0.1 --udp -4 -f K -b $R -l 8920 -t 30 -i 5 -P 64 -O 2 where $R is either 1G/10G/0 (max, unlimited). I ran 3 times each. baseline is v6.9-rc3. harmean == harmonic mean; CV == coefficient of variation. ipv4: 1G 10G MAX HARMEAN (CV) HARMEAN (CV) HARMEAN (CV) baseline 1743852.66(0.0208) 1725933.02(0.0167) 1705203.78(0.0386) patched 1968727.61(0.0035) 1962283.22(0.0195) 1923853.50(0.0256) ipv6: 1G 10G MAX HARMEAN (CV) HARMEAN (CV) HARMEAN (CV) baseline 1729020.03(0.0028) 1691704.49(0.0243) 1692251.34(0.0083) patched 1900422.19(0.0067) 1900968.01(0.0067) 1568532.72(0.1519) This restores the performance we had before the change above with this benchmark. We obviously don't expect any real impact when mitigations are disabled, but just to be sure it also doesn't regresses: mitigations=off ipv4: 1G 10G MAX HARMEAN (CV) HARMEAN (CV) HARMEAN (CV) baseline 3230279.97(0.0066) 3229320.91(0.0060) 2605693.19(0.0697) patched 3242802.36(0.0073) 3239310.71(0.0035) 2502427.19(0.0882) Cc: Lorenz Bauer <lmb@isovalent.com> Fixes: f0ea27e7 ("udp: re-score reuseport groups when connected sockets are present") Signed-off-by:
Gabriel Krisman Bertazi <krisman@suse.de> Reviewed-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Breno Leitao authored
Commit 3e2f544d ("net: get stats64 if device if driver is configured") moved the callback to dev_get_tstats64() to net core, so, unless the driver is doing some custom stats collection, it does not need to set .ndo_get_stats64. Since this driver is now relying in NETDEV_PCPU_STAT_TSTATS, then, it doesn't need to set the dev_get_tstats64() generic .ndo_get_stats64 function pointer. Signed-off-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
-
Breno Leitao authored
With commit 34d21de9 ("net: Move {l,t,d}stats allocation to core and convert veth & vrf"), stats allocation could be done on net core instead of in this driver. With this new approach, the driver doesn't have to bother with error handling (allocation failure checking, making sure free happens in the right spot, etc). This is core responsibility now. Remove the allocation in the ip6_gre and leverage the network core allocation instead. Signed-off-by:
-
Russell King (Oracle) authored
Convert dsa_user_phylink_fixed_state() to use the newly introduced dsa_phylink_to_port() helper. Suggested-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Heiner Kallweit authored
AFAICS all users of net_class take a const struct class * argument. Therefore fully constify net_class. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Acked-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
John Fraker authored
gve has supported software timestamp generation since its inception, but has not advertised that support via ethtool. This patch correctly advertises that support. Signed-off-by:
John Fraker <jfraker@google.com> Reviewed-by:
Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by:
-
Jason Xing authored
Normally, we don't face these two exceptions very often meanwhile we have some chance to meet the condition where the current cpu id is the same as skb->alloc_cpu. One simple test that can help us see the frequency of this statement 'cpu == raw_smp_processor_id()': 1. running iperf -s and iperf -c [ip] -P [MAX CPU] 2. using BPF to capture skb_attempt_defer_free() I can see around 4% chance that happens to satisfy the statement. So moving this statement at the beginning can save some cycles in most cases. Signed-off-by:
Jason Xing <kernelxing@tencent.com> Reviewed-by:
Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by:
-
David S. Miller authored
Asbjørn Sloth Tønnesen says: ==================== flower: validate control flags I have reviewed the flower control flags code. In all, but one (sfc), the flags field wasn't checked properly for unsupported flags. In this series I have only included a single example user for each helper function. Once the helpers are in, I will submit patches for all other drivers implementing flower. After which there will be: - 6 drivers using flow_rule_is_supp_control_flags() - 8 drivers using flow_rule_has_control_flags() - 11 drivers using flow_rule_match_has_control_flags() --- Changelog: v3: - Added Reviewed-by from Louis Peens (first two patches) - Properly fixed kernel-doc format v2: https://lore.kernel.org/netdev/20240410093235.5334-1-ast@fiberby.net/ - Squashed the 3 helper functions to one commmit (requested by Baowen Zheng) - Renamed helper functions to avoid double negatives (suggested by Louis Peens) - Reverse booleans in some functions and callsites to align with new names - Fix autodoc format v1: https://lore.kernel.org/netdev/20240408130927.78594-1-ast@fiberby.net/ ==================== Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
Add check for unsupported control flags. Only compile-tested, no access to HW. Signed-off-by:
Asbjørn Sloth Tønnesen <ast@fiberby.net> Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
Add check for unsupported control flags. Only compile-tested, no access to HW. Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
Use flow_rule_is_supp_control_flags() Check the mask, not the key, for unsupported control flags. Only compile-tested, no access to HW Signed-off-by:
Louis Peens <louis.peens@corigine.com> Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
These helpers aim to help drivers, with checking for the presence of unsupported control flags. For drivers supporting at least one control flag: flow_rule_is_supp_control_flags() For drivers using flow_rule_match_control(), but not using flags: flow_rule_has_control_flags() For drivers not using flow_rule_match_control(): flow_rule_match_has_control_flags() While primarily aimed at FLOW_DISSECTOR_KEY_CONTROL and flow_rule_match_control(), then the first two can also be used with FLOW_DISSECTOR_KEY_ENC_CONTROL and flow_rule_match_enc_control(). These helpers mirrors the existing check done in sfc: drivers/net/ethernet/sfc/tc.c +276 Only compile-tested. Signed-off-by:
-
Jakub Kicinski authored
We lock and unlock rtnl in init/exit for convenience, but it started causing problems if the exit is handled by a different thread. To avoid having to futz with disabling locking assertions move the locking into the test cases. We don't use ASSERTs so it should be safe. ============= dev-addr-list-test (6 subtests) ============== [PASSED] dev_addr_test_basic [PASSED] dev_addr_test_sync_one [PASSED] dev_addr_test_add_del [PASSED] dev_addr_test_del_main [PASSED] dev_addr_test_add_set [PASSED] dev_addr_test_add_excl =============== [PASSED] dev-addr-list-test ================ Link: https://lore.kernel.org/all/20240403131936.787234-7-linux@roeck-us.netSigned-off-by:
-
Wander Lairson Costa authored
trace_drop_common() is called with preemption disabled, and it acquires a spin_lock. This is problematic for RT kernels because spin_locks are sleeping locks in this configuration, which causes the following splat: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47 preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 2 5 locks held by rcuc/47/449: #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210 #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130 #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210 #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70 #4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290 irq event stamp: 139909 hardirqs last enabled at (139908): [<ffffffffb1df2b33>] _raw_spin_unlock_irqrestore+0x63/0x80 hardirqs last disabled at (139909): [<ffffffffb19bd03d>] trace_drop_common.constprop.0+0x26d/0x290 softirqs last enabled at (139892): [<ffffffffb07a1083>] __local_bh_enable_ip+0x103/0x170 softirqs last disabled at (139898): [<ffffffffb0909b33>] rcu_cpu_kthread+0x93/0x1f0 Preemption disabled at: [<ffffffffb1de786b>] rt_mutex_slowunlock+0xab/0x2e0 CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7 Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022 Call Trace: <TASK> dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 __might_resched+0x21e/0x2f0 rt_spin_lock+0x5e/0x130 ? trace_drop_common.constprop.0+0xb5/0x290 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_drop_common.constprop.0+0xb5/0x290 ? preempt_count_sub+0x1c/0xd0 ? _raw_spin_unlock_irqrestore+0x4a/0x80 ? __pfx_trace_drop_common.constprop.0+0x10/0x10 ? rt_mutex_slowunlock+0x26a/0x2e0 ? skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_rt_mutex_slowunlock+0x10/0x10 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_kfree_skb_hit+0x15/0x20 trace_kfree_skb+0xe9/0x150 kfree_skb_reason+0x7b/0x110 skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10 ? mark_lock.part.0+0x8a/0x520 ... trace_drop_common() also disables interrupts, but this is a minor issue because we could easily replace it with a local_lock. Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic context. Signed-off-by:Wander Lairson Costa <wander@redhat.com> Reported-by:
Hu Chunyu <chuhu@redhat.com> Signed-off-by:
-
- 13 Apr, 2024 14 commits
-
-
Eric Dumazet authored
- fib rules are already RCU protected, RTNL is not needed to get them. - Fix return value at the end of a dump, so that NLMSG_DONE can be appended to current skb, saving one recvmsg() system call. Signed-off-by:
-
Colin Ian King authored
Variable err is being assigned a zero value and it is never read afterwards in either the break path or continue path, the assignment is redundant and can be removed. With it removed, the if statement can also be simplified. Cleans up clang scan warning: net/tipc/socket.c:3570:5: warning: Value stored to 'err' is never read [deadcode.DeadStores] Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20240411091704.306752-1-colin.i.king@gmail.comSigned-off-by:
-
Eric Dumazet authored
When TCP_TW_SYN is processed, we perform a lookup to find a listener and jump back in tcp_v6_rcv() and tcp_v4_rcv() Paolo suggested that we do not have to check if the found socket is a TIME_WAIT or NEW_SYN_RECV one. Suggested-by:
Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/netdev/68085c8a84538cacaac991415e4ccc72f45e76c2.camel@redhat.com/Signed-off-by:
-
Jakub Kicinski authored
Jijie Shao says: ==================== Support some features for the HNS3 ethernet driver Currently, the hns3 driver does not have the trace of the command queue. As a result, it is difficult to locate the communication between the driver and firmware. Therefore, the trace function of the command queue is added in this patch set to facilitate the locating of communication problems between the driver and firmware. If a RAS occurs, the driver will automatically reset to attempt to recover the RAS. Therefore, to locate the cause of the RAS, it is necessary to save the values of some RAS-related registers before the reset. So we added a patch in this patch set to print these information. ==================== Link: https://lore.kernel.org/r/20240410125354.2177067-1-shaojijie@huawei.comSigned-off-by:
-
Hao Chen authored
Add support to query scc version by devlink info for device V3. Signed-off-by:
Hao Chen <chenhao418@huawei.com> Signed-off-by:
Jijie Shao <shaojijie@huawei.com> Link: https://lore.kernel.org/r/20240410125354.2177067-5-shaojijie@huawei.comSigned-off-by:
-
Peiyang Wang authored
When the driver received an interrupte for hardware error, it will try to restore by resetting. But the hardware registers will also be reset at this case, which make it hard to analysis why the hardware error occurs. This patch dumps these registers before resetting to help analyze the hardware error occurs. Signed-off-by:
Peiyang Wang <wangpeiyang1@huawei.com> Signed-off-by:
Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240410125354.2177067-4-shaojijie@huawei.comSigned-off-by:
-
Jijie Shao authored
some constants are defined in hclge_debugfs.h, but only used in hclge_debugfs.c. so move them from hclge_debugfs.h to hclge_debugfs.c. Signed-off-by:
-
Hao Lan authored
Add support to dump command queue trace for hns3. Signed-off-by:
Hao Lan <lanhao@huawei.com> Signed-off-by:
-
Lin Ma authored
Revert "NFC: fix attrs checks in netlink interface" This reverts commit 18917d51. Our checks found weird attrs present check in function nfc_genl_dep_link_down() and nfc_genl_llc_get_params(), which are introduced by commit 18917d51 ("NFC: fix attrs checks in netlink interface"). According to its message, it should add checks for functions nfc_genl_deactivate_target() and nfc_genl_fw_download(). However, it didn't do that. In fact, the expected checks are added by (1) commit 385097a3 ("nfc: Ensure presence of required attributes in the deactivate_target handler") and (2) commit 280e3ebd ("nfc: Ensure presence of NFC_ATTR_FIRMWARE_NAME attribute in nfc_genl_fw_download()"). Perhaps something went wrong. Anyway, the attr NFC_ATTR_TARGET_INDEX is never accessed in callback nfc_genl_dep_link_down() and same for NFC_ATTR_FIRMWARE_NAME and nfc_genl_llc_get_params(). Thus, remove those checks. Signed-off-by:
Lin Ma <linma@zju.edu.cn> Link: https://lore.kernel.org/r/20240410034846.167421-1-linma@zju.edu.cnSigned-off-by:
-
Jakub Kicinski authored
Uwe Kleine-König says: ==================== ptp: Convert to platform remove callback returning void this series converts all platform drivers below drivers/ptp/ to not use struct platform_device::remove() any more. See commit 5c5a7680 ("platform: Provide a remove callback that returns no value") for an extended explanation and the eventual goal. All conversations are trivial, because the driver's .remove() callbacks returned zero unconditionally. ==================== Link: https://lore.kernel.org/r/cover.1712734365.git.u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Richard Cochran <richardcochran@gmail.com> Link: https://lore.kernel.org/r/477c6995046eee729447d4f88bf042c7577fe100.1712734365.git.u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
