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 <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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 <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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 <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Factor out mcast_packet_test into lib.sh so it can be later extended and
reused by MLDv2 tests.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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 <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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 <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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 <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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 <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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 <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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: Alex Elder <elder@linaro.org>
Link: https://lore.kernel.org/r/20201102173435.5987-1-elder@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20201102121615.695196-1-colin.king@canonical.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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 <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Tested-by: Camelia Groza <camelia.groza@nxp.com>

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>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Tested-by: Camelia Groza <camelia.groza@nxp.com>

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: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
Cc: Herbert XS <herbert@gondor.apana.org.au>
Cc: Li Yang <leoyang.li@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Tested-by: Camelia Groza <camelia.groza@nxp.com>

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: Jakub Kicinski <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/a52a6de4-f792-5038-ae2f-240d3b7860eb@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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: Alexander Lobakin <alobakin@pm.me>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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 <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20201102114512.1062724-29-lee.jones@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

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: Lee Jones <lee.jones@linaro.org>
Acked-by: Hayes Wang <hayeswang@realtek.com>
Link: https://lore.kernel.org/r/20201102114512.1062724-28-lee.jones@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

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 <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20201102114512.1062724-27-lee.jones@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

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 <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20201102114512.1062724-26-lee.jones@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

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: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20201102114512.1062724-25-lee.jones@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Fixes the following W=1 kernel build warning(s):

 drivers/net/ieee802154/ca8210.c:724: warning: Function parameter or member 'cas_ctl' not described in 'ca8210_rx_done'
 drivers/net/ieee802154/ca8210.c:724: warning: Excess function parameter 'cas_ctrl' description in 'ca8210_rx_done'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
Link: https://lore.kernel.org/r/20201102114512.1062724-24-lee.jones@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Fixes the following W=1 kernel build warning(s):

 drivers/net/usb/r8152.c:934: warning: Function parameter or member 'blk_hdr' not described in 'fw_mac'
 drivers/net/usb/r8152.c:934: warning: Function parameter or member 'reserved' not described in 'fw_mac'
 drivers/net/usb/r8152.c:947: warning: Function parameter or member 'blk_hdr' not described in 'fw_phy_patch_key'
 drivers/net/usb/r8152.c:947: warning: Function parameter or member 'reserved' not described in 'fw_phy_patch_key'
 drivers/net/usb/r8152.c:986: warning: Function parameter or member 'blk_hdr' not described in 'fw_phy_nc'
 drivers/net/usb/r8152.c:986: warning: Function parameter or member 'mode_pre' not described in 'fw_phy_nc'
 drivers/net/usb/r8152.c:986: warning: Function parameter or member 'mode_post' not described in 'fw_phy_nc'
 drivers/net/usb/r8152.c:986: warning: Function parameter or member 'reserved' not described in 'fw_phy_nc'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Hayes Wang <hayeswang@realtek.com>
Link: https://lore.kernel.org/r/20201102114512.1062724-23-lee.jones@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Fixes the following W=1 kernel build warning(s):

 drivers/net/ieee802154/ca8210.c:326: warning: Function parameter or member 'readq' not described in 'ca8210_test'
 drivers/net/ieee802154/ca8210.c:375: warning: Function parameter or member 'spi_transfer_complete' not described in 'ca8210_priv'
 drivers/net/ieee802154/ca8210.c:375: warning: Function parameter or member 'sync_exchange_complete' not described in 'ca8210_priv'
 drivers/net/ieee802154/ca8210.c:375: warning: Function parameter or member 'promiscuous' not described in 'ca8210_priv'
 drivers/net/ieee802154/ca8210.c:430: warning: Function parameter or member 'short_address' not described in 'macaddr'
 drivers/net/ieee802154/ca8210.c:723: warning: Function parameter or member 'cas_ctl' not described in 'ca8210_rx_done'
 drivers/net/ieee802154/ca8210.c:723: warning: Excess function parameter 'arg' description in 'ca8210_rx_done'
 drivers/net/ieee802154/ca8210.c:1289: warning: Excess function parameter 'device_ref' description in 'tdme_checkpibattribute'
 drivers/net/ieee802154/ca8210.c:3054: warning: Function parameter or member 'spi_device' not described in 'ca8210_remove'
 drivers/net/ieee802154/ca8210.c:3054: warning: Excess function parameter 'priv' description in 'ca8210_remove'
 drivers/net/ieee802154/ca8210.c:3104: warning: Function parameter or member 'spi_device' not described in 'ca8210_probe'
 drivers/net/ieee802154/ca8210.c:3104: warning: Excess function parameter 'priv' description in 'ca8210_probe'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
Link: https://lore.kernel.org/r/20201102114512.1062724-21-lee.jones@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>