Commits · 74d155be2677a6e0df0a41487d3ca217bd756604 · Kirill Smelkov / linux

04 Nov, 2020 36 commits

net: phy: realtek: Add support for RTL8221B-CG series · 74d155be

Willy Liu authored Nov 02, 2020

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>

74d155be

Merge branch 'fsl-qbman-in_interrupt-cleanup' · 45e9fbf0

Jakub Kicinski authored Nov 03, 2020

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>

45e9fbf0

crypto: caam: Replace in_irq() usage. · de3f5d9e

Sebastian Andrzej Siewior authored Nov 02, 2020

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>

de3f5d9e

net: dpaa: Replace in_irq() usage. · abba4b16

Sebastian Andrzej Siewior authored Nov 02, 2020

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>

abba4b16

soc/fsl/qbman: Add an argument to signal if NAPI processing is required. · f84754db

Sebastian Andrzej Siewior authored Nov 02, 2020

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>

f84754db

lan743x: fix for potential NULL pointer dereference with bare card · e9e13b6a

Sergej Bauer authored Nov 02, 2020

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>

e9e13b6a

r8169: set IRQF_NO_THREAD if MSI(X) is enabled · 870f531e

Heiner Kallweit authored Nov 01, 2020

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>

870f531e

r8169: align number of tx descriptors with vendor driver · f06059c2

Heiner Kallweit authored Nov 01, 2020

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>

f06059c2

Merge branch 'mlxsw-spectrum-prepare-for-xm-implementation-lpm-trees' · 923ba95e

Jakub Kicinski authored Nov 03, 2020

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>

923ba95e

mlxsw: spectrum_router: Introduce low-level ops and implement them for RALXX regs · 803be108

Jiri Pirko authored Nov 01, 2020

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>

803be108

mlxsw: reg: Add XRALXX Registers · fb281f24

Jiri Pirko authored Nov 01, 2020

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>

fb281f24

Merge branch 'net-allow-virtual-netdevs-to-forward-udp-l4-and-fraglist-gso-skbs' · 8e6a0485

Jakub Kicinski authored Nov 03, 2020

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>

8e6a0485

net: bonding, dummy, ifb, team: advertise NETIF_F_GSO_SOFTWARE · ecb8fed4

Alexander Lobakin authored Nov 01, 2020

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>

ecb8fed4

net: add GSO UDP L4 and GSO fraglists to the list of software-backed types · 2e4ef10f

Alexander Lobakin authored Nov 01, 2020

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>

2e4ef10f