- 05 Nov, 2020 15 commits
-
-
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions INCLUDE (A) IS_EX (B) EXCLUDE (A*B, B-A) (B-A)=0 Delete (A-B) Filter Timer=MALI Signed-off-by:Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=MALI Signed-off-by:
-
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=MALI Signed-off-by:
-
Nikolay Aleksandrov authored
Add the initial setup for MLDv2 tests with the first test of a simple is_include report. For MLDv2 we need to setup the bridge properly and we also send the full precooked packets instead of relying on mausezahn to fill in some parts. For verification we use the generic S,G state checking functions from lib.sh. Signed-off-by:
-
Nikolay Aleksandrov authored
Factor out S,G entry state checking functions for existence, forwarding, blocking and timer to lib.sh so they can be later used by MLDv2 tests. Add brmcast_ suffix to their name to make the relation to the bridge explicit. Signed-off-by:
-
Nikolay Aleksandrov authored
In order to test an IPv6 multicast packet we need to pass different tc and mausezahn protocols only, so add a simple check for the destination address which decides if we should generate an IPv4 or IPv6 mcast packet. Signed-off-by:
-
Nikolay Aleksandrov authored
Factor out mcast_packet_test into lib.sh so it can be later extended and reused by MLDv2 tests. Signed-off-by:
-
DENG Qingfang authored
MT7530/7531 has a global RX packet length register, which can be used to set MTU. Supported packet length values are 1522 (1518 if untagged), 1536, 1552, and multiple of 1024 (from 2048 to 15360). Signed-off-by:
DENG Qingfang <dqfext@gmail.com> Link: https://lore.kernel.org/r/20201103050618.11419-1-dqfext@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: tell GSI the IPA version The GSI code that supports IPA avoids having knowledge about the IPA layer it serves. One result of this is that Boolean flags are used during GSI initialization to convey that certain hardware version-dependent special behaviors should be used. A given version of IPA hardware uses a fixed/well-defined version of GSI, so the IPA version really implies the GSI version. If given only the IPA version, the GSI code supporting IPA can use it to implement certain special behaviors required for IPA *or* GSI. This avoids the need to pass and maintain numerous Boolean flags. ==================== Link: https://lore.kernel.org/r/20201102175400.6282-1-elder@linaro.orgSigned-off-by:
-
Alex Elder authored
We enable a channel doorbell engine only for IPA v3.5.1, and that is now handled directly by gsi_channel_program(). When initially setting up a channel, we want that doorbell engine enabled, and we can request that independent of the IPA version. Doing that makes the "legacy" argument to gsi_channel_setup_one() unnecessary. And with that gone we can get rid of the "legacy" argument to gsi_channel_setup(), and gsi_setup() as well. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
Use the IPA version in gsi_channel_program() to determine whether we should enable the GSI doorbell engine when requested. This way, callers only say whether or not it should be enabled if needed, regardless of hardware version. Rename the "legacy" argument to gsi_channel_reset(), and have it indicate whether the doorbell engine should be enabled when reprogramming following the reset. Change all callers of gsi_channel_reset() to indicate whether to enable the doorbell engine after reset, independent of hardware version. Rework a little logic in ipa_endpoint_reset() to get rid of the "legacy" variable previously passed to gsi_channel_reset(). Signed-off-by:
-
Alex Elder authored
A quirk of IPA v3.5.1 requires a channel reset on an RX channel to be performed twice. Use the IPA version in gsi_channel_reset() rather than the passed-in legacy flag to determine that. This is actually a bug fix, because this double reset is supposed to occur independent of whether we're enabling the doorbell engine. Now they will be independent. Signed-off-by:
-
Alex Elder authored
A quirk of IPA v4.2 requires the AP to allocate the GSI channels that are owned by the modem. Rather than pass a flag argument to gsi_channel_init(), use the IPA version directly in that function to determine whether modem channels need to be allocated. Signed-off-by:
-
Alex Elder authored
Record the IPA version passed to gsi_init() in the GSI structure. This allows that value to be used directly where needed, rather than passing and storing certain flag arguments through the code. In particular, for all but one supported version of IPA, the command channel is programmed to only use an "escape buffer". By storing the IPA version, we can do a simple version check in one location, and avoid storing a flag field in every channel (and passing a flag along while initializing channels to set that field properly). Signed-off-by:
-
Alex Elder authored
Although GSI is integral to IPA, it is a separate hardware component and the IPA code supporting it has been structured to avoid explicit dependence on IPA details. An example of this is that gsi_init() is passed a number of Boolean flags to indicate special behaviors, whose values are dependent on the IPA hardware version. Looking ahead, newer hardware versions would require even more such special behaviors. For any given version of IPA hardware (like 3.5.1 or 4.2), the GSI hardware version is fixed (in this case, 1.3 and 2.2, respectively). So the IPA version *implies* the GSI version, and the IPA version can be used as effectively the equivalent of the GSI hardware version. Rather than proliferating new special behavior flags, just provide the IPA version to the GSI layer when it is initialized. The GSI code can then use that directly to determine whether special behaviors are required. The IPA version enumerated type is already isolated to its own header file, so the exposure of this IPA detail is very limited. For now, just change gsi_init() to pass the version rather than the Boolean flags, and set the flag values internal to that function. Signed-off-by:
-
- 04 Nov, 2020 25 commits
-
-
Alex Elder authored
With IPA v3.5.1, if IPA aggregation is active at the time an underlying GSI channel reset is performed, some special handling is required. There is logic in ipa_endpoint_reset() that arranges for that special handling, but it's done for all hardware versions, not just IPA v3.5.1. Fix the logic to properly restrict the special behavior. Signed-off-by:
-
Vinay Kumar Yadav authored
patch adds a logic to utilize multiple queues to process requests. The queue selection logic uses a round-robin distribution technique using a counter. Signed-off-by:
Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by:
Vinay Kumar Yadav <vinay.yadav@chelsio.com> Link: https://lore.kernel.org/r/20201102162832.22344-1-vinay.yadav@chelsio.comSigned-off-by:
-
Colin Ian King authored
An incorrect sizeof() is being used, sizeof(u64 *) is not correct, it should be sizeof(*sq->sqb_ptrs). Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)") Signed-off-by:Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201102134601.698436-1-colin.king@canonical.comSigned-off-by:
-
Colin Ian King authored
The variable err is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
kernel test robot authored
Condition !A || A && B is equivalent to !A || B. Generated by: scripts/coccinelle/misc/excluded_middle.cocci Fixes: b76f0ea0 ("coccinelle: misc: add excluded_middle.cocci script") CC: Denis Efremov <efremov@linux.com> Signed-off-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Julia Lawall <julia.lawall@inria.fr> Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2011020936100.3077@hadrienSigned-off-by:
-
Willy Liu authored
Realtek single-port 2.5Gbps Ethernet PHYs are list as below: RTL8226-CG: the 1st generation 2.5Gbps single port PHY RTL8226B-CG/RTL8221B-CG: the 2nd generation 2.5Gbps single port PHY RTL8221B-VB-CG: the 3rd generation 2.5Gbps single port PHY RTL8221B-VM-CG: the 2.5Gbps single port PHY with MACsec feature This patch adds the minimal drivers to manage these transceivers. Signed-off-by:
Willy Liu <willy.liu@realtek.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/1604281927-9874-1-git-send-email-willy.liu@realtek.comSigned-off-by:
-
Jakub Kicinski authored
Sebastian Andrzej Siewior says: ==================== fsl/qbman: in_interrupt() cleanup. This is the in_interrupt() clean for FSL DPAA framework and the two users. The `napi' parameter has been renamed to `sched_napi', the other parts are same as in the previous post [0]. [0] https://lkml.kernel.org/r/20201027225454.3492351-1-bigeasy@linutronix.de ==================== Link: https://lore.kernel.org/r/20201101232257.3028508-1-bigeasy@linutronix.deSigned-off-by:
-
Sebastian Andrzej Siewior authored
The driver uses in_irq() + in_serving_softirq() magic to decide if NAPI scheduling is required or packet processing. The usage of in_*() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. Use the `sched_napi' argument passed by the callback. It is set true if called from the interrupt handler and NAPI should be scheduled. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Li Yang <leoyang.li@nxp.com> Reviewed-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
Madalin Bucur <madalin.bucur@oss.nxp.com> Tested-by:
Camelia Groza <camelia.groza@nxp.com>
-
Sebastian Andrzej Siewior authored
The driver uses in_irq() + in_serving_softirq() magic to decide if NAPI scheduling is required or packet processing. The usage of in_*() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. Use the `sched_napi' argument passed by the callback. It is set true if called from the interrupt handler and NAPI should be scheduled. Signed-off-by:
-
Sebastian Andrzej Siewior authored
dpaa_eth_napi_schedule() and caam_qi_napi_schedule() schedule NAPI if invoked from: - Hard interrupt context - Any context which is not serving soft interrupts Any context which is not serving soft interrupts includes hard interrupts so the in_irq() check is redundant. caam_qi_napi_schedule() has a comment about this: /* * In case of threaded ISR, for RT kernels in_irq() does not return * appropriate value, so use in_serving_softirq to distinguish between * softirq and irq contexts. */ if (in_irq() || !in_serving_softirq()) This has nothing to do with RT. Even on a non RT kernel force threaded interrupts run obviously in thread context and therefore in_irq() returns false when invoked from the handler. The extension of the in_irq() check with !in_serving_softirq() was there when the drivers were added, but in the out of tree FSL BSP the original condition was in_irq() which got extended due to failures on RT. The usage of in_xxx() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. Right he is, the above construct is clearly showing why. The following callchains have been analyzed to end up in dpaa_eth_napi_schedule(): qman_p_poll_dqrr() __poll_portal_fast() fq->cb.dqrr() dpaa_eth_napi_schedule() portal_isr() __poll_portal_fast() fq->cb.dqrr() dpaa_eth_napi_schedule() Both need to schedule NAPI. The crypto part has another code path leading up to this: kill_fq() empty_retired_fq() qman_p_poll_dqrr() __poll_portal_fast() fq->cb.dqrr() dpaa_eth_napi_schedule() kill_fq() is called from task context and ends up scheduling NAPI, but that's pointless and an unintended side effect of the !in_serving_softirq() check. The code path: caam_qi_poll() -> qman_p_poll_dqrr() is invoked from NAPI and I *assume* from crypto's NAPI device and not from qbman's NAPI device. I *guess* it is okay to skip scheduling NAPI (because this is what happens now) but could be changed if it is wrong due to `budget' handling. Add an argument to __poll_portal_fast() which is true if NAPI needs to be scheduled. This requires propagating the value to the caller including `qman_cb_dqrr' typedef which is used by the dpaa and the crypto driver. Signed-off-by: -
Sergej Bauer authored
This is the 3rd revision of the patch fix for potential null pointer dereference with lan743x card. The simpliest way to reproduce: boot with bare lan743x and issue "ethtool ethN" commant where ethN is the interface with lan743x card. Example: $ sudo ethtool eth7 dmesg: [ 103.510336] BUG: kernel NULL pointer dereference, address: 0000000000000340 ... [ 103.510836] RIP: 0010:phy_ethtool_get_wol+0x5/0x30 [libphy] ... [ 103.511629] Call Trace: [ 103.511666] lan743x_ethtool_get_wol+0x21/0x40 [lan743x] [ 103.511724] dev_ethtool+0x1507/0x29d0 [ 103.511769] ? avc_has_extended_perms+0x17f/0x440 [ 103.511820] ? tomoyo_init_request_info+0x84/0x90 [ 103.511870] ? tomoyo_path_number_perm+0x68/0x1e0 [ 103.511919] ? tty_insert_flip_string_fixed_flag+0x82/0xe0 [ 103.511973] ? inet_ioctl+0x187/0x1d0 [ 103.512016] dev_ioctl+0xb5/0x560 [ 103.512055] sock_do_ioctl+0xa0/0x140 [ 103.512098] sock_ioctl+0x2cb/0x3c0 [ 103.512139] __x64_sys_ioctl+0x84/0xc0 [ 103.512183] do_syscall_64+0x33/0x80 [ 103.512224] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 103.512274] RIP: 0033:0x7f54a9cba427 ... Previous versions can be found at: v1: initial version https://lkml.org/lkml/2020/10/28/921 v2: do not return from lan743x_ethtool_set_wol if netdev->phydev == NULL, just skip the call of phy_ethtool_set_wol() instead. https://lkml.org/lkml/2020/10/31/380 v3: in function lan743x_ethtool_set_wol: use ternary operator instead of if-else sentence (review by Markus Elfring) return -ENETDOWN insted of -EIO (review by Andrew Lunn) Signed-off-by:Sergej Bauer <sbauer@blackbox.su> Link: https://lore.kernel.org/r/20201101223556.16116-1-sbauer@blackbox.suSigned-off-by:
-
Heiner Kallweit authored
We had to remove flag IRQF_NO_THREAD because it conflicts with shared interrupts in case legacy interrupts are used. Following up on the linked discussion set IRQF_NO_THREAD if MSI or MSI-X is used, because both guarantee that interrupt won't be shared. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://www.spinics.net/lists/netdev/msg695341.html Link: https://lore.kernel.org/r/446cf5b8-dddd-197f-cb96-66783141ade4@gmail.comSigned-off-by:
-
Heiner Kallweit authored
Lowest number of tx descriptors used in the vendor drivers is 256 in r8169. r8101/r8168/r8125 use 1024 what seems to be the hw limit. Stay on the safe side and go with 256, same as number of rx descriptors. Signed-off-by:
-
Jakub Kicinski authored
Ido Schimmel says: ==================== mlxsw: spectrum: Prepare for XM implementation - LPM trees Jiri says: This is a preparation patchset for follow-up support of boards with extended mezzanine (XM), which are going to allow extended (scale-wise) router offload. XM requires a separate set of PRM registers to be used to configure LPM trees. Therefore, this patchset introduces operations that allow different implementations of tree configuration for legacy router offload and the XM router offload. ==================== Link: https://lore.kernel.org/r/20201101134215.713708-1-idosch@idosch.orgSigned-off-by:
-
Jiri Pirko authored
In preparation for support of XM router implementation which uses different registers to work with trees and FIB entries, introduce a structure to hold low-level ops and implement tree manipulation register ops. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Jiri Pirko authored
Add a couple of registers used to manipulate LPM trees on XM: The XRALTA is used to allocate the XLT LPM trees. The XRALST is used to set and query the structure of an XLT LPM tree. The XRALTB register is used to bind virtual router and protocol to an allocated LPM tree. Since the XM registers are identical to the legacy router registers with a fixed offset, re-use their pack functions. Signed-off-by:
-
Jakub Kicinski authored
Alexander Lobakin says: ==================== net: allow virtual netdevs to forward UDP L4 and fraglist GSO skbs NETIF_F_GSO_UDP_L4 and NETIF_F_GSO_FRAGLIST allow drivers to offload GSO UDP L4. This works well on simple setups, but when any logical netdev (e.g. VLAN) is present, kernel stack always performs software resegmentation which actually kills the performance. The full path in such cases is like: 1. Our NIC driver advertises a support for fraglists, GSO UDP L4, GSO fraglists. 2. User enables fraglisted GRO via Ethtool. 3. GRO subsystem receives UDP frames from driver and merges the packets into fraglisted GSO skb(s). 4. Networking stack queues it up for xmitting. 5. Virtual device like VLAN doesn't advertise a support for GSO UDP L4 and GSO fraglists, so skb_gso_check() doesn't allow to pass this skb as is to the real driver. 6. Kernel then has to form a bunch of regular UDP skbs from that one and pass it to the driver instead. This fallback is *extremely* slow for any GSO types, but especially for GSO fraglists. 7. All further processing performs with a series of plain UDP skbs, and the driver gets it one-by-one, despite that it supports UDP L4 and fraglisted GSO. That's not OK because: a) logical/virtual netdevs like VLANs, bridges etc. should pass GSO skbs as is; b) even if the final driver doesn't support such type of GSO, this software resegmenting should be performed right before it, not in the middle of processing -- I think I even saw that note somewhere in kernel documentation, and it's totally reasonable in terms of performance. Despite the fact that no mainline drivers currently supports fraglist GSO, this should and can be easily fixed by adding UDP L4 and fraglist GSO to the list of GSO types that can be passed-through the logical interfaces (NETIF_F_GSO_SOFTWARE). After this change, no resegmentation occurs (if a particular driver supports and advertises this), and the performance goes on par with e.g. 1:1 forwarding. The only logical netdevs that seem to be unaffected to this are bridge interfaces, as their code uses full NETIF_F_GSO_MASK. Tested on MIPS32 R2 router board with a WIP NIC driver in VLAN NAT: 20 Mbps baseline, 1 Gbps / link speed with this patch. Since v1 [1]: - handle bonding and team drivers as suggested by Willem de Bruijn; - reword and expand the introduction with the particular example. [1] https://lore.kernel.org/netdev/Mx3BWGop6fGORN6Cpo4mHIHz2b1bb0eLxeMG8vsijnk@cp3-web-020.plabs.ch ==================== Link: https://lore.kernel.org/r/NysZRGMkuWq0KPTCJ1Dz2FTjRkeJXDH3edVrsEeJkQI@cp4-web-036.plabs.chSigned-off-by:
-
Alexander Lobakin authored
Virtual netdevs should use NETIF_F_GSO_SOFTWARE to forward GSO skbs as-is and let the final drivers deal with them when supported. Also remove NETIF_F_GSO_UDP_L4 from bonding and team drivers as it's now included in the "software" list. Suggested-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Acked-by:
-
Alexander Lobakin authored
Commit e20cf8d3 ("udp: implement GRO for plain UDP sockets.") and commit 9fd1ff5d ("udp: Support UDP fraglist GRO/GSO.") made UDP L4 and fraglisted GRO/GSO fully supported by the software fallback mode. We can safely add them to NETIF_F_GSO_SOFTWARE to allow logical/virtual netdevs to forward these types of skbs up to the real drivers. Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/net/net_failover.c:711: warning: Function parameter or member 'standby_dev' not described in 'net_failover_create' drivers/net/net_failover.c:711: warning: Excess function parameter 'dev' description in 'net_failover_create' Signed-off-by:
Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20201102114512.1062724-30-lee.jones@linaro.orgSigned-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/net/netconsole.c:104: warning: Function parameter or member 'extended' not described in 'netconsole_target' Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/net/usb/r8152.c:992: warning: Function parameter or member 'mode_pre' not described in 'fw_phy_nc' drivers/net/usb/r8152.c:992: warning: Function parameter or member 'mode_post' not described in 'fw_phy_nc' Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Link: https://lore.kernel.org/r/20201102114512.1062724-28-lee.jones@linaro.orgSigned-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/net/macvlan.c:1350: warning: Function parameter or member 'vlan' not described in 'macvlan_changelink_sources' drivers/net/macvlan.c:1350: warning: Function parameter or member 'mode' not described in 'macvlan_changelink_sources' drivers/net/macvlan.c:1350: warning: Function parameter or member 'data' not described in 'macvlan_changelink_sources' Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/net/macsec.c:113: warning: Function parameter or member 'gro_cells' not described in 'macsec_dev' Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/net/usb/lan78xx.c: In function ‘lan78xx_read_raw_otp’: drivers/net/usb/lan78xx.c:825:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_write_raw_otp’: drivers/net/usb/lan78xx.c:879:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_deferred_multicast_write’: drivers/net/usb/lan78xx.c:1041:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_update_flowcontrol’: drivers/net/usb/lan78xx.c:1127:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_init_mac_address’: drivers/net/usb/lan78xx.c:1666:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_link_status_change’: drivers/net/usb/lan78xx.c:1841:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_irq_bus_sync_unlock’: drivers/net/usb/lan78xx.c:1920:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan8835_fixup’: drivers/net/usb/lan78xx.c:1994:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_set_rx_max_frame_length’: drivers/net/usb/lan78xx.c:2192:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_change_mtu’: drivers/net/usb/lan78xx.c:2270:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_set_mac_addr’: drivers/net/usb/lan78xx.c:2299:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_set_features’: drivers/net/usb/lan78xx.c:2333:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_set_suspend’: drivers/net/usb/lan78xx.c:3807:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Signed-off-by:
-
