Krzysztof Kozlowski [Wed, 25 Aug 2021 14:24:56 +0000 (16:24 +0200)]
nfc: pn544: remove unused header includes
Do not include unnecessary headers.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Krzysztof Kozlowski [Wed, 25 Aug 2021 14:24:55 +0000 (16:24 +0200)]
nfc: mrvl: remove unused header includes
Do not include unnecessary headers.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Krzysztof Kozlowski [Wed, 25 Aug 2021 14:24:54 +0000 (16:24 +0200)]
nfc: microread: remove unused header includes
Do not include unnecessary headers.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 25 Aug 2021 12:44:30 +0000 (13:44 +0100)]
Merge branch 'pktgen-samples-next'
Juhee Kang says:
====================
samples: pktgen: enhance the ability to print the execution results of samples
This patch series improves the ability to print the execution result of pktgen
samples by adding a line which calls the function before termination and adding
trap SIGINT. Also, this series documents the latest pktgen usage options.
Currently, pktgen samples print the execution result when terminated usually.
However, sample03 is not working properly.
This is results of sample04 and sample03:
# DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample04_many_flows.sh -n 1
Running... ctrl^C to stop
Device: eth0@0
Result: OK: 19(c5+d13) usec, 1 (60byte,0frags)
51762pps 24Mb/sec (24845760bps) errors: 0
# DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample03_burst_single_flow.sh -n 1
Running... ctrl^C to stop
Because sample03 doesn't call the function which prints the execution result
when terminated normally, unlike other samples. So the first commit solves
this issue by adding a line which calls the function before termination.
Also, all pktgen samples are able to send infinite messages per thread by
setting the count option to 0, and pktgen is stopped by Ctrl-C. However,
the sample besides sample{3...5} don't work appropriately because Ctrl-C stops
the script, not just pktgen.
This is results of samples:
# DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample04_many_flows.sh -n 0
Running... ctrl^C to stop
^CDevice: eth0@0
Result: OK: 569657(c569538+d118) usec, 84650 (60byte,0frags)
148597pps 71Mb/sec (71326560bps) errors: 0
# DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample01_simple.sh -n 0
Running... ctrl^C to stop
^C
# DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample02_multiqueue.sh -n 0
Running... ctrl^C to stop
^C
# DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample06_numa_awared_queue_irq_affinity.sh -n 0
Running... ctrl^C to stop
^C
# DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_bench_xmit_mode_netif_receive.sh -n 0
Running... ctrl^C to stop
^C
# DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_bench_xmit_mode_queue_xmit.sh -n 0
Running... ctrl^C to stop
^C
So the second commit solves this issue by adding trap SIGINT. Also, changes
control_c function to print_results to maintain consistency with other samples
on the first commit and second commit.
And current pktgen.rst documentation doesn't add the latest pktgen sample
usage options such as count and IPv6, and so on. Also, the old pktgen
sample scripts are still included in the document. The old scripts were removed
by the commit
a4b6ade8359f ("samples/pktgen: remove remaining old pktgen
sample scripts").
Thus, the last commit documents the latest pktgen sample usage and removes
old sample scripts. And fixes a minor typo.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Juhee Kang [Wed, 25 Aug 2021 10:57:17 +0000 (19:57 +0900)]
pktgen: document the latest pktgen usage options
Currently, the pktgen.rst documentation doesn't cover the latest pktgen
sample usage options such as count and IPv6, and so on. Also, this
documentation includes the old sample scripts which are no longer use
because it was removed by the commit
a4b6ade8359f ("samples/pktgen :
remove remaining old pktgen sample scripts")
Thus, this commit documents pktgen sample usage using the latest options
and removes old sample scripts, and fixes a minor typo.
Signed-off-by: Juhee Kang <claudiajkang@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Juhee Kang [Wed, 25 Aug 2021 10:57:16 +0000 (19:57 +0900)]
samples: pktgen: add trap SIGINT for printing execution result
All pktgen samples can send indefinitely num messages per thread by
setting the count option to 0(-n 0). If running sample with setting
count 0 and press Ctrl-C to stop this program, the program prints the
result of the execution so far. Currently, the samples besides
sample{3...5} don't work properly. Because Ctrl-C stops the script, not
just pktgen.
This is results of samples:
# DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample04_many_flows.sh -n 0
Running... ctrl^C to stop
^CDevice: eth0@0
Result: OK: 569657(c569538+d118) usec, 84650 (60byte,0frags)
148597pps 71Mb/sec (71326560bps) errors: 0
# DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample01_simple.sh -n 0
Running... ctrl^C to stop
^C
In order to solve this, this commit adds trap SIGINT. Also, this commit
changes control_c function to print_result to maintain consistency with
other samples.
Signed-off-by: Juhee Kang <claudiajkang@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Juhee Kang [Wed, 25 Aug 2021 10:57:15 +0000 (19:57 +0900)]
samples: pktgen: fix to print when terminated normally
Currently, most pktgen samples print the execution result when the
program is terminated normally. However, sample03 doesn't work
appropriately.
This is results of samples:
# DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample04_many_flows.sh -n 1
Running... ctrl^C to stop
Device: eth0@0
Result: OK: 19(c5+d13) usec, 1 (60byte,0frags)
51762pps 24Mb/sec (24845760bps) errors: 0
# DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample03_burst_single_flow.sh -n 1
Running... ctrl^C to stop
The reason why it doesn't print the execution result when the program is
terminated usually is that sample03 doesn't call the function which
prints the result, unlike other samples.
So, this commit solves this issue by calling the function before
termination. Also, this commit changes control_c function to
print_result to maintain consistency with other samples.
Signed-off-by: Juhee Kang <claudiajkang@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 25 Aug 2021 12:39:02 +0000 (13:39 +0100)]
Merge branch 'octeontx2-traffic-shaping'
Sunil Goutham says:
====================
Octeontx2: Traffic shaping and SDP link config support
This patch series adds support for traffic shaping configuration
on all silicons available after 96xx C0. And also adds SDP link
related configuration needed when Octeon is connected as an end-point
and traffic needs to flow from end-point to host and vice versa.
Series also has other changes like
- New mbox messages in admin function driver for PF/VF drivers
to retrieve available HW resource count. HW resources like block LFs,
bandwidth profiles etc are covered.
- Added PTP device ID for new CN10K and 95O silicons.
- etc
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Sunil Goutham [Wed, 25 Aug 2021 12:18:46 +0000 (17:48 +0530)]
octeontx2-af: Add mbox to retrieve bandwidth profile free count
Added mbox for PF/VF drivers to retrieve current ingress bandwidth
profile free count. Also added current policer timeunit
configuration info based on which ratelimiting decisions can be
taken by PF/VF drivers.
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sunil Goutham [Wed, 25 Aug 2021 12:18:45 +0000 (17:48 +0530)]
octeontx2-af: Remove channel verification while installing MCAM rules
New usecases are popping up where in user wants to install common MCAM
filters for all interfaces. Having channel verification will result in
duplicating such MCAM filters for each of the ingress interface. Hence
removed channel verification.
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Subbaraya Sundeep [Wed, 25 Aug 2021 12:18:44 +0000 (17:48 +0530)]
octeontx2-af: Add PTP device id for CN10K and 95O silcons
CN10K slicon has different device id for PTP device.
Hence this patch updates the driver with new id.
Though ptp driver being a separate driver AF manages
configuring PTP block by all PFs. To manage ptp, AF
driver checks in its probe whether
1. ptp hardware device found on silicon
2. A driver is bound to ptp device
3. The ptp driver probe is successful
In failure of cases 1 and 3, AF proceeds with out ptp
and for case 2 defers the probe. This patch refactors
code also to check for all the PTP device ids given in
ptp device ids table for case 1.
Also added PTP device ID for 95O silicon
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
George Cherian [Wed, 25 Aug 2021 12:18:43 +0000 (17:48 +0530)]
octeontx2-af: Add free rsrc count mbox msg
Upon receiving the MBOX_MSG_FREE_RSRC_CNT, the AF will find out the
current number of free resources and reply it back to the requester. No
guarantee is given on the future state of the free resources yet.
If another requester sends MBOX_MSG_ATTACH_RESOURCES after this call,
the number of available resources might change.
Signed-off-by: George Cherian <george.cherian@marvell.com>
Signed-off-by: Stanislaw Kardach <skardach@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Radha Mohan Chintakuntla [Wed, 25 Aug 2021 12:18:42 +0000 (17:48 +0530)]
octeontx2-af: Add SDP interface support
Added support for packet IO via SDK links which is used when
Octeon is connected as a end-point. Traffic host to end-point
and vice versa flow through SDP links. This patch also support
dual SDP blocks supported in 98xx silicon.
Signed-off-by: Radha Mohan Chintakuntla <radhac@marvell.com>
Signed-off-by: Nalla Pradeep <pnalla@marvell.com>
Signed-off-by: Subrahmanyam Nilla <snilla@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Harman Kalra [Wed, 25 Aug 2021 12:18:41 +0000 (17:48 +0530)]
octeontx2-af: nix and lbk in loop mode in 98xx
In 98xx, there are 2 NIX blocks and 4 LBK blocks present. The way
these NIX-LBK should be configured depends on the use case. By
default loopback functionality is supported in AF VF pairs which
are attached to NIX0 and NIX1 LFs alternatively to ensure load
balancing. NIX0 transmits a packet to LBK1 which will be received
by NIX1 and packet transmitted by NIX1 will get received by NIX0 via
LBK2.
There are some requirements where only one AF VF is used and respective
NIX is expected to operate in a mode where it can receive it own packet
back. This can be achieved if NIX0 sends packet to LBK0 and not LBK1.
Adding a flag in LF alloc request mailbox which can setup NIX0 to use
LBK0 and NIX1 can use LBK3.
Signed-off-by: Harman Kalra <hkalra@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Subbaraya Sundeep [Wed, 25 Aug 2021 12:18:40 +0000 (17:48 +0530)]
octeontx2-pf: cleanup transmit link deriving logic
Unlike OcteonTx2, the channel numbers used by CGX/RPM
and LBK on CN10K silicons aren't fixed in HW. They are
SW programmable, hence we cannot derive transmit link
from static channel numbers anymore. Get the same from
admin function via mailbox.
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jerin Jacob [Wed, 25 Aug 2021 12:18:39 +0000 (17:48 +0530)]
octeontx2-af: Allow to configure flow tag LSB byte as RSS adder
Before C0 HW revision, The RSS adder was computed based the
following static formula.
rss_adder<7:0> = flow_tag<7:0> ^ flow_tag<15:8> ^
flow_tag<23:16> ^ flow_tag<31:24>
The above scheme has the following drawbacks:
1) It is not in line with other standard NIC behavior.
2) There can be an SW use case where SW can compute the hash
upfront using Toeplitz function and predict the queue selection
to optimize some packet lookup function. The nonstandard
way of doing XOR makes the consumer to not predict the queue selection.
C0 HW revision onwards, The HW can configure the
rss_adder<7:0> as flow_tag<7:0> to align with standard NICs.
This patch adds an option to select legacy RSS adder mode
vs standard NIC behavior by setting NIX_LF_RSS_TAG_LSB_AS_ADDER flag.
Since this bit field is used as reserved in old HW revisions,
No need to have an additional HW version check.
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Nithin Dabilpuram [Wed, 25 Aug 2021 12:18:38 +0000 (17:48 +0530)]
octeontx2-af: enable tx shaping feature for 96xx C0
Starting from 96xx C0 onwards all silicons support traffic shaping.
This patch enables that feature along with other changes
- When PIR/CIR shaping config is modified, toggle SW_XOFF
for config to take effect
- Before SMQ flush, clear SW_XOFF at all parent schedulers
- Support to read current transmit scheduler configuration via mbox
Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cai Huoqing [Wed, 25 Aug 2021 06:25:13 +0000 (14:25 +0800)]
net: ethernet: actions: Add helper dependency on COMPILE_TEST
it's helpful for complie test in other platform(e.g.X86)
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Nithin Dabilpuram [Wed, 25 Aug 2021 05:46:21 +0000 (11:16 +0530)]
octeontx2-af: Wait for TX link idle for credits change
NIX_AF_TX_LINKX_NORM_CREDIT holds running counter of
tx credits available per link. But, tx credits should be
configured based on MTU config. So MTU change needs tx
credit count update.
An issue exists whereby when both PF & VF are enabled and
PF traffic is flowing, if VF requests for MTU update,
updating the NORM_CREDIT register will lead to corruption
of credit count and subsequent deadlock of tx link as
the NORM_CREDIT register holds running count.
This patch provides workaround by pausing link traffic
using NIX_AF_TL1X_SW_XOFF, waiting for existing packets to
drain, and used credits be returned before updating new
credit count.
Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Nithin Dabilpuram [Wed, 25 Aug 2021 05:39:04 +0000 (11:09 +0530)]
octeontx2-af: Change the order of queue work and interrupt disable
Clear and disable interrupt before queueing work as there might be
a chance that work gets completed on other core faster and
interrupt enable as a part of the work completes before
interrupt disable in the interrupt context. This leads to
permanent disable of interrupt.
Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Geetha sowjanya [Wed, 25 Aug 2021 05:35:03 +0000 (11:05 +0530)]
octeontx2-af: cn10k: Set cache lines for NPA batch alloc
Set NPA batch allocation engine to process 35 cache lines
per turn on CN10k platform.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Shaokun Zhang [Wed, 25 Aug 2021 06:34:31 +0000 (14:34 +0800)]
mctp: Remove the repeated declaration
Function 'mctp_dev_get_rtnl' is declared twice, so remove the
repeated declaration.
Cc: Jeremy Kerr <jk@codeconstruct.com.au>
Cc: Matt Johnston <matt@codeconstruct.com.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 25 Aug 2021 10:19:38 +0000 (11:19 +0100)]
Merge tag 'linux-can-next-for-5.15-
20210825' of git://git./linux/kernel/git/mkl/linux-can-next
Marc Kleine says:
====================
pull-request: can-next 2021-08-25
this is a pull request of 4 patches for net-next/master.
The first patch is by Cai Huoqing, and enables COMPILE_TEST for the
rcar CAN drivers.
Lad Prabhakar contributes a patch for the rcar_canfd driver, fixing a
redundant assignment.
The last 2 patches are by Tang Bin, target the mscan driver, and clean
up the driver by converting it to of_device_get_match_data() and
removing a useless BUG_ON.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 25 Aug 2021 10:18:17 +0000 (11:18 +0100)]
Merge branch 'ravb-gbit-refactor'
Biju Das says:
====================
Add Factorisation code to support Gigabit Ethernet driver
The DMAC and EMAC blocks of Gigabit Ethernet IP found on RZ/G2L SoC are
similar to the R-Car Ethernet AVB IP.
The Gigabit Ethernet IP consists of Ethernet controller (E-MAC), Internal
TCP/IP Offload Engine (TOE) and Dedicated Direct memory access controller
(DMAC).
With a few changes in the driver we can support both IPs.
This patch series aims to add factorisation code to support RZ/G2L SoC,
hardware feature bits for gPTP feature, Multiple irq feature and
optional reset support.
Ref:-
* https://lore.kernel.org/linux-renesas-soc/TYCPR01MB59334319695607A2683C1A5E86E59@TYCPR01MB5933.jpnprd01.prod.outlook.com/T/#t
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:54 +0000 (08:01 +0100)]
ravb: Add reset support
Reset support is present on R-Car. Let's support it, if it is
available.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:53 +0000 (08:01 +0100)]
ravb: Factorise ravb_emac_init function
The E-MAC IP on the R-Car AVB module has different initialization
parameters for RX frame size, duplex settings, different offset
for transfer speed setting and has magic packet detection support
compared to E-MAC on RZ/G2L Gigabit Ethernet module. Factorise
the ravb_emac_init function to support the later SoC.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:52 +0000 (08:01 +0100)]
ravb: Factorise ravb_dmac_init function
The DMAC IP on the R-Car AVB module has different initialization
parameters for RCR, TGC, TCCR, RIC0, RIC2, and TIC compared to
DMAC IP on the RZ/G2L Gigabit Ethernet module. Factorise the
ravb_dmac_init function to support the later SoC.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:51 +0000 (08:01 +0100)]
ravb: Factorise ravb_set_features
RZ/G2L supports HW checksum on RX and TX whereas R-Car supports on RX.
Factorise ravb_set_features to support this feature.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:50 +0000 (08:01 +0100)]
ravb: Factorise ravb_adjust_link function
R-Car supports 100 and 1000 Mbps transfer speed whereas RZ/G2L
in addition support 10Mbps. Factorise ravb_adjust_link function
in order to support 10Mbps speed.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:49 +0000 (08:01 +0100)]
ravb: Factorise ravb_rx function
R-Car uses an extended descriptor in RX whereas, RZ/G2L uses
normal descriptor in RX. Factorise the ravb_rx function to
support the later SoC.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:48 +0000 (08:01 +0100)]
ravb: Factorise ravb_ring_init function
The ravb_ring_init function uses an extended descriptor in RX for
R-Car and normal descriptor for RZ/G2L. Add a helper function
for RX ring buffer allocation to support later SoC.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:47 +0000 (08:01 +0100)]
ravb: Factorise ravb_ring_format function
The ravb_ring_format function uses an extended descriptor in RX
for R-Car compared to the normal descriptor for RZ/G2L. Factorise
RX ring buffer buildup to extend the support for later SoC.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:46 +0000 (08:01 +0100)]
ravb: Factorise ravb_ring_free function
R-Car uses extended descriptor in RX, whereas RZ/G2L uses normal
descriptor. Factorise ravb_ring_free function so that it can
support later SoC.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:45 +0000 (08:01 +0100)]
ravb: Add ptp_cfg_active to struct ravb_hw_info
There are some H/W differences for the gPTP feature between
R-Car Gen3, R-Car Gen2, and RZ/G2L as below.
1) On R-Car Gen3, gPTP support is active in config mode.
2) On R-Car Gen2, gPTP support is not active in config mode.
3) RZ/G2L does not support the gPTP feature.
Add a ptp_cfg_active hw feature bit to struct ravb_hw_info for
supporting gPTP active in config mode for R-Car Gen3.
This patch also removes enum ravb_chip_id, chip_id from both
struct ravb_hw_info and struct ravb_private, as it is unused.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:44 +0000 (08:01 +0100)]
ravb: Add no_ptp_cfg_active to struct ravb_hw_info
There are some H/W differences for the gPTP feature between
R-Car Gen3, R-Car Gen2, and RZ/G2L as below.
1) On R-Car Gen2, gPTP support is not active in config mode.
2) On R-Car Gen3, gPTP support is active in config mode.
3) RZ/G2L does not support the gPTP feature.
Add a no_ptp_cfg_active hw feature bit to struct ravb_hw_info for
handling gPTP for R-Car Gen2.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:43 +0000 (08:01 +0100)]
ravb: Add multi_irq to struct ravb_hw_info
R-Car Gen3 supports separate interrupts for E-MAC and DMA queues,
whereas R-Car Gen2 and RZ/G2L have a single interrupt instead.
Add a multi_irq hw feature bit to struct ravb_hw_info to enable
this only for R-Car Gen3.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Biju Das [Wed, 25 Aug 2021 07:01:42 +0000 (08:01 +0100)]
ravb: Remove the macros NUM_TX_DESC_GEN[23]
For addressing 4 bytes alignment restriction on transmission
buffer for R-Car Gen2 we use 2 descriptors whereas it is a single
descriptor for other cases.
Replace the macros NUM_TX_DESC_GEN[23] with magic number and
add a comment to explain it.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 25 Aug 2021 10:14:34 +0000 (11:14 +0100)]
Merge branch 'dsa-sja1105-vlan-tags'
Vladimir Oltean says:
====================
Make sja1105 treat tag_8021q VLANs more like real DSA tags
This series solves a nuisance with the sja1105 driver, which is that
non-DSA tagged packets sent directly by the DSA master would still exit
the switch just fine.
We also had an issue for packets coming from the outside world with a
crafted DSA tag, the switch would not reject that tag but think it was
valid.
====================
Vladimir Oltean [Tue, 24 Aug 2021 17:15:02 +0000 (20:15 +0300)]
net: dsa: tag_sja1105: stop asking the sja1105 driver in sja1105_xmit_tpid
Introduced in commit
38b5beeae7a4 ("net: dsa: sja1105: prepare tagger
for handling DSA tags and VLAN simultaneously"), the sja1105_xmit_tpid
function solved quite a different problem than our needs are now.
Then, we used best-effort VLAN filtering and we were using the xmit_tpid
to tunnel packets coming from an 8021q upper through the TX VLAN allocated
by tag_8021q to that egress port. The need for a different VLAN protocol
depending on switch revision came from the fact that this in itself was
more of a hack to trick the hardware into accepting tunneled VLANs in
the first place.
Right now, we deny 8021q uppers (see sja1105_prechangeupper). Even if we
supported them again, we would not do that using the same method of
{tunneling the VLAN on egress, retagging the VLAN on ingress} that we
had in the best-effort VLAN filtering mode. It seems rather simpler that
we just allocate a VLAN in the VLAN table that is simply not used by the
bridge at all, or by any other port.
Anyway, I have 2 gripes with the current sja1105_xmit_tpid:
1. When sending packets on behalf of a VLAN-aware bridge (with the new
TX forwarding offload framework) plus untagged (with the tag_8021q
VLAN added by the tagger) packets, we can see that on SJA1105P/Q/R/S
and later (which have a qinq_tpid of ETH_P_8021AD), some packets sent
through the DSA master have a VLAN protocol of 0x8100 and others of
0x88a8. This is strange and there is no reason for it now. If we have
a bridge and are therefore forced to send using that bridge's TPID,
we can as well blend with that bridge's VLAN protocol for all packets.
2. The sja1105_xmit_tpid introduces a dependency on the sja1105 driver,
because it looks inside dp->priv. It is desirable to keep as much
separation between taggers and switch drivers as possible. Now it
doesn't do that anymore.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 24 Aug 2021 17:15:01 +0000 (20:15 +0300)]
net: dsa: sja1105: drop untagged packets on the CPU and DSA ports
The sja1105 driver is a bit special in its use of VLAN headers as DSA
tags. This is because in VLAN-aware mode, the VLAN headers use an actual
TPID of 0x8100, which is understood even by the DSA master as an actual
VLAN header.
Furthermore, control packets such as PTP and STP are transmitted with no
VLAN header as a DSA tag, because, depending on switch generation, there
are ways to steer these control packets towards a precise egress port
other than VLAN tags. Transmitting control packets as untagged means
leaving a door open for traffic in general to be transmitted as untagged
from the DSA master, and for it to traverse the switch and exit a random
switch port according to the FDB lookup.
This behavior is a bit out of line with other DSA drivers which have
native support for DSA tagging. There, it is to be expected that the
switch only accepts DSA-tagged packets on its CPU port, dropping
everything that does not match this pattern.
We perhaps rely a bit too much on the switches' hardware dropping on the
CPU port, and place no other restrictions in the kernel data path to
avoid that. For example, sja1105 is also a bit special in that STP/PTP
packets are transmitted using "management routes"
(sja1105_port_deferred_xmit): when sending a link-local packet from the
CPU, we must first write a SPI message to the switch to tell it to
expect a packet towards multicast MAC DA 01-80-c2-00-00-0e, and to route
it towards port 3 when it gets it. This entry expires as soon as it
matches a packet received by the switch, and it needs to be reinstalled
for the next packet etc. All in all quite a ghetto mechanism, but it is
all that the sja1105 switches offer for injecting a control packet.
The driver takes a mutex for serializing control packets and making the
pairs of SPI writes of a management route and its associated skb atomic,
but to be honest, a mutex is only relevant as long as all parties agree
to take it. With the DSA design, it is possible to open an AF_PACKET
socket on the DSA master net device, and blast packets towards
01-80-c2-00-00-0e, and whatever locking the DSA switch driver might use,
it all goes kaput because management routes installed by the driver will
match skbs sent by the DSA master, and not skbs generated by the driver
itself. So they will end up being routed on the wrong port.
So through the lens of that, maybe it would make sense to avoid that
from happening by doing something in the network stack, like: introduce
a new bit in struct sk_buff, like xmit_from_dsa. Then, somewhere around
dev_hard_start_xmit(), introduce the following check:
if (netdev_uses_dsa(dev) && !skb->xmit_from_dsa)
kfree_skb(skb);
Ok, maybe that is a bit drastic, but that would at least prevent a bunch
of problems. For example, right now, even though the majority of DSA
switches drop packets without DSA tags sent by the DSA master (and
therefore the majority of garbage that user space daemons like avahi and
udhcpcd and friends create), it is still conceivable that an aggressive
user space program can open an AF_PACKET socket and inject a spoofed DSA
tag directly on the DSA master. We have no protection against that; the
packet will be understood by the switch and be routed wherever user
space says. Furthermore: there are some DSA switches where we even have
register access over Ethernet, using DSA tags. So even user space
drivers are possible in this way. This is a huge hole.
However, the biggest thing that bothers me is that udhcpcd attempts to
ask for an IP address on all interfaces by default, and with sja1105, it
will attempt to get a valid IP address on both the DSA master as well as
on sja1105 switch ports themselves. So with IP addresses in the same
subnet on multiple interfaces, the routing table will be messed up and
the system will be unusable for traffic until it is configured manually
to not ask for an IP address on the DSA master itself.
It turns out that it is possible to avoid that in the sja1105 driver, at
least very superficially, by requesting the switch to drop VLAN-untagged
packets on the CPU port. With the exception of control packets, all
traffic originated from tag_sja1105.c is already VLAN-tagged, so only
STP and PTP packets need to be converted. For that, we need to uphold
the equivalence between an untagged and a pvid-tagged packet, and to
remember that the CPU port of sja1105 uses a pvid of 4095.
Now that we drop untagged traffic on the CPU port, non-aggressive user
space applications like udhcpcd stop bothering us, and sja1105 effectively
becomes just as vulnerable to the aggressive kind of user space programs
as other DSA switches are (ok, users can also create 8021q uppers on top
of the DSA master in the case of sja1105, but in future patches we can
easily deny that, but it still doesn't change the fact that VLAN-tagged
packets can still be injected over raw sockets).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 24 Aug 2021 17:15:00 +0000 (20:15 +0300)]
net: dsa: sja1105: prevent tag_8021q VLANs from being received on user ports
Currently it is possible for an attacker to craft packets with a fake
DSA tag and send them to us, and our user ports will accept them and
preserve that VLAN when transmitting towards the CPU. Then the tagger
will be misled into thinking that the packets came on a different port
than they really came on.
Up until recently there wasn't a good option to prevent this from
happening. In SJA1105P and later, the MAC Configuration Table introduced
two options called:
- DRPSITAG: Drop Single Inner Tagged Frames
- DRPSOTAG: Drop Single Outer Tagged Frames
Because the sja1105 driver classifies all VLANs as "outer VLANs" (S-Tags),
it would be in principle possible to enable the DRPSOTAG bit on ports
using tag_8021q, and drop on ingress all packets which have a VLAN tag.
When the switch is VLAN-unaware, this works, because it uses a custom
TPID of 0xdadb, so any "tagged" packets received on a user port are
probably a spoofing attempt. But when the switch overall is VLAN-aware,
and some ports are standalone (therefore they use tag_8021q), the TPID
is 0x8100, and the port can receive a mix of untagged and VLAN-tagged
packets. The untagged ones will be classified to the tag_8021q pvid, and
the tagged ones to the VLAN ID from the packet header. Yes, it is true
that since commit
4fbc08bd3665 ("net: dsa: sja1105: deny 8021q uppers on
ports") we no longer support this mixed mode, but that is a temporary
limitation which will eventually be lifted. It would be nice to not
introduce one more restriction via DRPSOTAG, which would make the
standalone ports of a VLAN-aware switch drop genuinely VLAN-tagged
packets.
Also, the DRPSOTAG bit is not available on the first generation of
switches (SJA1105E, SJA1105T). So since one of the key features of this
driver is compatibility across switch generations, this makes it an even
less desirable approach.
The breakthrough comes from commit
bef0746cf4cc ("net: dsa: sja1105:
make sure untagged packets are dropped on ingress ports with no pvid"),
where it became obvious that untagged packets are not dropped even if
the ingress port is not in the VMEMB_PORT vector of that port's pvid.
However, VLAN-tagged packets are subject to VLAN ingress
checking/dropping. This means that instead of using the catch-all
DRPSOTAG bit introduced in SJA1105P, we can drop tagged packets on a
per-VLAN basis, and this is already compatible with SJA1105E/T.
This patch adds an "allowed_ingress" argument to sja1105_vlan_add(), and
we call it with "false" for tag_8021q VLANs on user ports. The tag_8021q
VLANs still need to be allowed, of course, on ingress to DSA ports and
CPU ports.
We also need to refine the drop_untagged check in sja1105_commit_pvid to
make it not freak out about this new configuration. Currently it will
try to keep the configuration consistent between untagged and pvid-tagged
packets, so if the pvid of a port is 1 but VLAN 1 is not in VMEMB_PORT,
packets tagged with VID 1 will behave the same as untagged packets, and
be dropped. This behavior is what we want for ports under a VLAN-aware
bridge, but for the ports with a tag_8021q pvid, we want untagged
packets to be accepted, but packets tagged with a header recognized by
the switch as a tag_8021q VLAN to be dropped. So only restrict the
drop_untagged check to apply to the bridge_pvid, not to the tag_8021q_pvid.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
DENG Qingfang [Tue, 24 Aug 2021 16:52:52 +0000 (00:52 +0800)]
net: dsa: mt7530: manually set up VLAN ID 0
The driver was relying on dsa_slave_vlan_rx_add_vid to add VLAN ID 0. After
the blamed commit, VLAN ID 0 won't be set up anymore, breaking software
bridging fallback on VLAN-unaware bridges.
Manually set up VLAN ID 0 to fix this.
Fixes:
06cfb2df7eb0 ("net: dsa: don't advertise 'rx-vlan-filter' when not needed")
Signed-off-by: DENG Qingfang <dqfext@gmail.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 25 Aug 2021 10:06:54 +0000 (11:06 +0100)]
Merge branch 'mana-EQ-sharing'
Haiyang Zhang says:
====================
net: mana: Add support for EQ sharing
The existing code uses (1 + #vPorts * #Queues) MSIXs, which may exceed
the device limit.
Support EQ sharing, so that multiple vPorts can share the same set of
MSIXs.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Haiyang Zhang [Tue, 24 Aug 2021 16:46:01 +0000 (09:46 -0700)]
net: mana: Add WARN_ON_ONCE in case of CQE read overflow
This is not an expected case normally.
Add WARN_ON_ONCE in case of CQE read overflow, instead of failing
silently.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Haiyang Zhang [Tue, 24 Aug 2021 16:46:00 +0000 (09:46 -0700)]
net: mana: Add support for EQ sharing
The existing code uses (1 + #vPorts * #Queues) MSIXs, which may exceed
the device limit.
Support EQ sharing, so that multiple vPorts (NICs) can share the same
set of MSIXs.
And, report the EQ-sharing capability bit to the host, which means the
host can potentially offer more vPorts and queues to the VM.
Also update the resource limit checking and error handling for better
robustness.
Now, we support up to 256 virtual ports per VF (it was 16/VF), and
support up to 64 queues per vPort (it was 16).
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Haiyang Zhang [Tue, 24 Aug 2021 16:45:59 +0000 (09:45 -0700)]
net: mana: Move NAPI from EQ to CQ
The existing code has NAPI threads polling on EQ directly. To prepare
for EQ sharing among vPorts, move NAPI from EQ to CQ so that one EQ
can serve multiple CQs from different vPorts.
The "arm bit" is only set when CQ processing is completed to reduce
the number of EQ entries, which in turn reduce the number of interrupts
on EQ.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Shaokun Zhang [Wed, 25 Aug 2021 03:06:55 +0000 (11:06 +0800)]
netxen_nic: Remove the repeated declaration
Function 'netxen_rom_fast_read' is declared twice, so remove the
repeated declaration.
Cc: Manish Chopra <manishc@marvell.com>
Cc: Rahul Verma <rahulv@marvell.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Nathan Chancellor [Tue, 24 Aug 2021 20:51:04 +0000 (13:51 -0700)]
cxgb4: Properly revert VPD changes
Clang warns:
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:2785:2: error: variable 'kw_offset' is uninitialized when used here [-Werror,-Wuninitialized]
FIND_VPD_KW(i, "RV");
^~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:2776:39: note: expanded from macro 'FIND_VPD_KW'
var = pci_vpd_find_info_keyword(vpd, kw_offset, vpdr_len, name); \
^~~~~~~~~
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:2748:34: note: initialize the variable 'kw_offset' to silence this warning
unsigned int vpdr_len, kw_offset, id_len;
^
= 0
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:2785:2: error: variable 'vpdr_len' is uninitialized when used here [-Werror,-Wuninitialized]
FIND_VPD_KW(i, "RV");
^~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:2776:50: note: expanded from macro 'FIND_VPD_KW'
var = pci_vpd_find_info_keyword(vpd, kw_offset, vpdr_len, name); \
^~~~~~~~
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:2748:23: note: initialize the variable 'vpdr_len' to silence this warning
unsigned int vpdr_len, kw_offset, id_len;
^
= 0
2 errors generated.
The series "PCI/VPD: Convert more users to the new VPD API functions"
was applied to net-next when it should have been applied to the PCI tree
because of build errors. However, commit
82e34c8a9bdf ("Revert "Revert
"cxgb4: Search VPD with pci_vpd_find_ro_info_keyword()""") reapplied a
change, resulting in the warning above.
Properly revert commit
8d63ee602da3 ("cxgb4: Search VPD with
pci_vpd_find_ro_info_keyword()") to fix the warning and restore proper
functionality. This also reverts commit
3a93bedea050 ("cxgb4: Remove
unused vpd_param member ec") to avoid future merge conflicts, as that
change has been applied to the PCI tree.
Link: https://lore.kernel.org/r/20210823120929.7c6f7a4f@canb.auug.org.au/
Link: https://lore.kernel.org/r/1ca29408-7bc7-4da5-59c7-87893c9e0442@gmail.com/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 25 Aug 2021 10:02:35 +0000 (11:02 +0100)]
Merge branch 'mptcp-next'
Mat Martineau says:
====================
mptcp: Optimize output options and add MP_FAIL
This patch set contains two groups of changes that we've been testing in
the MPTCP tree.
The first optimizes the code path and data structure for populating
MPTCP option headers when transmitting.
Patch 1 reorganizes code to reduce the number of conditionals that need
to be evaluated in common cases.
Patch 2 rearranges struct mptcp_out_options to save 80 bytes (on x86_64).
The next five patches add partial support for the MP_FAIL option as
defined in RFC 8684. MP_FAIL is an option header used to cleanly handle
MPTCP checksum failures. When the MPTCP checksum detects an error in the
MPTCP DSS header or the data mapped by that header, the receiver uses a
TCP RST with MP_FAIL to close the subflow that experienced the error and
provide associated MPTCP sequence number information to the peer. RFC
8684 also describes how a single-subflow connection can discard corrupt
data and remain connected under certain conditions using MP_FAIL, but
that feature is not implemented here.
Patches 3-5 implement MP_FAIL transmit and receive, and integrates with
checksum validation.
Patches 6 & 7 add MP_FAIL selftests and the MIBs required for those
tests.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Geliang Tang [Tue, 24 Aug 2021 23:26:19 +0000 (16:26 -0700)]
selftests: mptcp: add MP_FAIL mibs check
This patch added a function chk_fail_nr to check the mibs for MP_FAIL.
Signed-off-by: Geliang Tang <geliangtang@xiaomi.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Geliang Tang [Tue, 24 Aug 2021 23:26:18 +0000 (16:26 -0700)]
mptcp: add the mibs for MP_FAIL
This patch added the mibs for MP_FAIL: MPTCP_MIB_MPFAILTX and
MPTCP_MIB_MPFAILRX.
Signed-off-by: Geliang Tang <geliangtang@xiaomi.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Geliang Tang [Tue, 24 Aug 2021 23:26:17 +0000 (16:26 -0700)]
mptcp: send out MP_FAIL when data checksum fails
When a bad checksum is detected, set the send_mp_fail flag to send out
the MP_FAIL option.
Add a new function mptcp_has_another_subflow() to check whether there's
only a single subflow.
When multiple subflows are in use, close the affected subflow with a RST
that includes an MP_FAIL option and discard the data with the bad
checksum.
Set the sk_state of the subsocket to TCP_CLOSE, then the flag
MPTCP_WORK_CLOSE_SUBFLOW will be set in subflow_sched_work_if_closed,
and the subflow will be closed.
When a single subfow is in use, temporarily handled by sending MP_FAIL
with a RST too.
Signed-off-by: Geliang Tang <geliangtang@xiaomi.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Geliang Tang [Tue, 24 Aug 2021 23:26:16 +0000 (16:26 -0700)]
mptcp: MP_FAIL suboption receiving
This patch added handling for receiving MP_FAIL suboption.
Add a new members mp_fail and fail_seq in struct mptcp_options_received.
When MP_FAIL suboption is received, set mp_fail to 1 and save the sequence
number to fail_seq.
Then invoke mptcp_pm_mp_fail_received to deal with the MP_FAIL suboption.
Signed-off-by: Geliang Tang <geliangtang@xiaomi.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Geliang Tang [Tue, 24 Aug 2021 23:26:15 +0000 (16:26 -0700)]
mptcp: MP_FAIL suboption sending
This patch added the MP_FAIL suboption sending support.
Add a new flag named send_mp_fail in struct mptcp_subflow_context. If
this flag is set, send out MP_FAIL suboption.
Add a new member fail_seq in struct mptcp_out_options to save the data
sequence number to put into the MP_FAIL suboption.
An MP_FAIL option could be included in a RST or on the subflow-level
ACK.
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Geliang Tang <geliangtang@xiaomi.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Paolo Abeni [Tue, 24 Aug 2021 23:26:14 +0000 (16:26 -0700)]
mptcp: shrink mptcp_out_options struct
After the previous patch we can alias with a union several
fields in mptcp_out_options. Such struct is stack allocated and
memset() for each plain TCP out packet. Every saved byted counts.
Before:
pahole -EC mptcp_out_options
# ...
/* size: 136, cachelines: 3, members: 17 */
After:
pahole -EC mptcp_out_options
# ...
/* size: 56, cachelines: 1, members: 9 */
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Paolo Abeni [Tue, 24 Aug 2021 23:26:13 +0000 (16:26 -0700)]
mptcp: optimize out option generation
Currently we have several protocol constraints on MPTCP options
generation (e.g. MPC and MPJ subopt are mutually exclusive)
and some additional ones required by our implementation
(e.g. almost all ADD_ADDR variant are mutually exclusive with
everything else).
We can leverage the above to optimize the out option generation:
we check DSS/MPC/MPJ presence in a mutually exclusive way,
avoiding many unneeded conditionals in the common cases.
Additionally extend the existing constraints on ADD_ADDR opt on
all subvariants, so that it becomes fully mutually exclusive with
the above and we can skip another conditional statement for the
common case.
This change is also needed by the next patch.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 25 Aug 2021 09:57:19 +0000 (10:57 +0100)]
Merge branch '1GbE' of git://git./linux/kernel/git/tnguy/next-queue
Tony Nguyen says:
====================
1GbE Intel Wired LAN Driver Updates 2021-08-24
Vinicius Costa Gomes says:
This adds support for PCIe PTM (Precision Time Measurement) to the igc
driver. PCIe PTM allows the NIC and Host clocks to be compared more
precisely, improving the clock synchronization accuracy.
Patch 1/4 reverts a commit that made pci_enable_ptm() private to the
PCI subsystem, reverting makes it possible for it to be called from
the drivers.
Patch 2/4 adds the pcie_ptm_enabled() helper.
Patch 3/4 calls pci_enable_ptm() from the igc driver.
Patch 4/4 implements the PCIe PTM support. Exposing it via the
.getcrosststamp() API implies that the time measurements are made
synchronously with the ioctl(). The hardware was implemented so the
most convenient way to retrieve that information would be
asynchronously. So, to follow the expectations of the ioctl() we have
to use less convenient ways, triggering an PCIe PTM dialog every time
a ioctl() is received.
Some questions are raised (also pointed out in the commit message):
1. Using convert_art_ns_to_tsc() is too x86 specific, there should be
a common way to create a 'system_counterval_t' from a timestamp.
2. convert_art_ns_to_tsc() says that it should only be used when
X86_FEATURE_TSC_KNOWN_FREQ is true, but during tests it works even
when it returns false. Should that check be done?
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 25 Aug 2021 09:55:43 +0000 (10:55 +0100)]
Merge branch 'lan7800-improvements'
John Efstathiades says:
====================
LAN7800 driver improvements
This patch set introduces a number of improvements and fixes for
problems found during testing of a modification to add a NAPI-style
approach to packet handling to improve performance.
NOTE: the NAPI changes are not part of this patch set and the issues
fixed by this patch set are not coupled to the NAPI changes.
Patch 1 fixes white space and style issues
Patch 2 removes an unused timer
Patch 3 introduces macros to set the internal packet FIFO flow
control levels, which makes it easier to update the levels in future.
Patch 4 removes an unused queue
Patch 5 (updated for v2) introduces function return value checks and
error propagation to various parts of the driver where a return
code was captured but then ignored.
This patch is completely different to patch 5 in version 1 of this patch
set. The changes in the v1 patch 5 are being set aside for the time
being.
Patch 6 updates the LAN7800 MAC reset code to ensure there is no
PHY register access in progress when the MAC is reset. This change
prevents a kernel exception that can otherwise occur.
Patch 7 fixes problems with system suspend and resume handling while
the device is transmitting and receiving data.
Patch 8 fixes problems with auto-suspend and resume handling and
depends on changes introduced by patch 7.
Patch 9 fixes problems with device disconnect handling that can result
in kernel exceptions and/or hang.
Patch 10 limits the rate at which driver warning messages are emitted.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
John Efstathiades [Tue, 24 Aug 2021 18:56:13 +0000 (19:56 +0100)]
lan78xx: Limit number of driver warning messages
Device removal can result in a large burst of driver warning messages
(20 - 30) sent to the kernel log. Most of these are register read/write
failures.
This change limits the rate at which these messages are emitted.
Signed-off-by: John Efstathiades <john.efstathiades@pebblebay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John Efstathiades [Tue, 24 Aug 2021 18:56:12 +0000 (19:56 +0100)]
lan78xx: Fix race condition in disconnect handling
If there is a device disconnect at roughly the same time as a
deferred PHY link reset there is a race condition that can result
in a kernel lock up due to a null pointer dereference in the
driver's deferred work handling routine lan78xx_delayedwork().
The following changes fix this problem.
Add new status flag EVENT_DEV_DISCONNECT to indicate when the
device has been removed and use it to prevent operations, such as
register access, that will fail once the device is removed.
Stop processing of deferred work items when the driver's USB
disconnect handler is invoked.
Disconnect the PHY only after the network device has been
unregistered and all delayed work has been cancelled.
Signed-off-by: John Efstathiades <john.efstathiades@pebblebay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John Efstathiades [Tue, 24 Aug 2021 18:56:11 +0000 (19:56 +0100)]
lan78xx: Fix race conditions in suspend/resume handling
If the interface is given an IP address while the device is
suspended (as a result of an auto-suspend event) there is a race
between lan78xx_resume() and lan78xx_open() that can result in an
exception or failure to handle incoming packets. The following
changes fix this problem.
Introduce a mutex to serialise operations in the network interface
open and stop entry points with respect to the USB driver suspend
and resume entry points.
Move Tx and Rx data path start/stop to lan78xx_start() and
lan78xx_stop() respectively and flush the packet FIFOs before
starting the Tx and Rx data paths. This prevents the MAC and FIFOs
getting out of step and delivery of malformed packets to the network
stack.
Stop processing of received packets before disconnecting the
PHY from the MAC to prevent a kernel exception caused by handling
packets after the PHY device has been removed.
Refactor device auto-suspend code to make it consistent with the
the system suspend code and make the suspend handler easier to read.
Add new code to stop wake-on-lan packets or PHY events resuming the
host or device from suspend if the device has not been opened
(typically after an IP address is assigned).
This patch is dependent on changes to lan78xx_suspend() and
lan78xx_resume() introduced in the previous patch of this patch set.
Signed-off-by: John Efstathiades <john.efstathiades@pebblebay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John Efstathiades [Tue, 24 Aug 2021 18:56:10 +0000 (19:56 +0100)]
lan78xx: Fix partial packet errors on suspend/resume
The MAC can get out of step with the internal packet FIFOs if the
system goes to sleep when the link is active, especially at high
data rates. This can result in partial frames in the packet FIFOs
that in result in malformed frames being delivered to the host.
This occurs because the driver does not enable/disable the internal
packet FIFOs in step with the corresponding MAC data path. The
following changes fix this problem.
Update code that enables/disables the MAC receiver and transmitter
to the more general Rx and Tx data path, where the data path in each
direction consists of both the MAC function (Tx or Rx) and the
corresponding packet FIFO.
In the receive path the packet FIFO must be enabled before the MAC
receiver but disabled after the MAC receiver.
In the transmit path the opposite is true: the packet FIFO must be
enabled after the MAC transmitter but disabled before the MAC
transmitter.
The packet FIFOs can be flushed safely once the corresponding data
path is stopped.
Signed-off-by: John Efstathiades <john.efstathiades@pebblebay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John Efstathiades [Tue, 24 Aug 2021 18:56:09 +0000 (19:56 +0100)]
lan78xx: Fix exception on link speed change
An exception is sometimes seen when the link speed is changed
from auto-negotiation to a fixed speed, or vice versa. The
exception occurs when the MAC is reset (due to the link speed
change) at the same time as the PHY state machine is accessing
a PHY register. The following changes fix this problem.
Rework the MAC reset to ensure there is no outstanding MDIO
register transaction before the reset and then wait until the
reset is complete before allowing any further MAC register access.
Signed-off-by: John Efstathiades <john.efstathiades@pebblebay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John Efstathiades [Tue, 24 Aug 2021 18:56:08 +0000 (19:56 +0100)]
lan78xx: Add missing return code checks
There are many places in the driver where the return code from a
function call is captured but without a subsequent test of the
return code and appropriate action taken.
This patch adds the missing return code tests and action. In most
cases the action is an early exit from the calling function.
The function lan78xx_set_suspend() was also updated to make it
consistent with lan78xx_suspend().
Signed-off-by: John Efstathiades <john.efstathiades@pebblebay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John Efstathiades [Tue, 24 Aug 2021 18:56:07 +0000 (19:56 +0100)]
lan78xx: Remove unused pause frame queue
Remove the pause frame queue from the driver. It is initialised
but not actually used.
Signed-off-by: John Efstathiades <john.efstathiades@pebblebay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John Efstathiades [Tue, 24 Aug 2021 18:56:06 +0000 (19:56 +0100)]
lan78xx: Set flow control threshold to prevent packet loss
Set threshold at which flow control is triggered to 3/4 full of
the internal Rx packet FIFO to prevent packet drops at high data
rates. The new setting reduces the number of dropped UDP frames
and TCP retransmit requests especially on less capable CPUs.
Signed-off-by: John Efstathiades <john.efstathiades@pebblebay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John Efstathiades [Tue, 24 Aug 2021 18:56:05 +0000 (19:56 +0100)]
lan78xx: Remove unused timer
Remove kernel timer that is not used by the driver.
Signed-off-by: John Efstathiades <john.efstathiades@pebblebay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John Efstathiades [Tue, 24 Aug 2021 18:56:04 +0000 (19:56 +0100)]
lan78xx: Fix white space and style issues
Fix white space and code style issues identified by checkpatch.
Signed-off-by: John Efstathiades <john.efstathiades@pebblebay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 25 Aug 2021 09:43:22 +0000 (10:43 +0100)]
Merge branch 'xen-harden-netfront'
Juergen Gross says:
====================
xen: harden netfront against malicious backends
Xen backends of para-virtualized devices can live in dom0 kernel, dom0
user land, or in a driver domain. This means that a backend might
reside in a less trusted environment than the Xen core components, so
a backend should not be able to do harm to a Xen guest (it can still
mess up I/O data, but it shouldn't be able to e.g. crash a guest by
other means or cause a privilege escalation in the guest).
Unfortunately netfront in the Linux kernel is fully trusting its
backend. This series is fixing netfront in this regard.
It was discussed to handle this as a security problem, but the topic
was discussed in public before, so it isn't a real secret.
It should be mentioned that a similar series has been posted some years
ago by Marek Marczykowski-Górecki, but this series has not been applied
due to a Xen header not having been available in the Xen git repo at
that time. Additionally my series is fixing some more DoS cases.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Juergen Gross [Tue, 24 Aug 2021 10:28:09 +0000 (12:28 +0200)]
xen/netfront: don't trust the backend response data blindly
Today netfront will trust the backend to send only sane response data.
In order to avoid privilege escalations or crashes in case of malicious
backends verify the data to be within expected limits. Especially make
sure that the response always references an outstanding request.
Note that only the tx queue needs special id handling, as for the rx
queue the id is equal to the index in the ring page.
Introduce a new indicator for the device whether it is broken and let
the device stop working when it is set. Set this indicator in case the
backend sets any weird data.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Juergen Gross [Tue, 24 Aug 2021 10:28:08 +0000 (12:28 +0200)]
xen/netfront: disentangle tx_skb_freelist
The tx_skb_freelist elements are in a single linked list with the
request id used as link reference. The per element link field is in a
union with the skb pointer of an in use request.
Move the link reference out of the union in order to enable a later
reuse of it for requests which need a populated skb pointer.
Rename add_id_to_freelist() and get_id_from_freelist() to
add_id_to_list() and get_id_from_list() in order to prepare using
those for other lists as well. Define ~0 as value to indicate the end
of a list and place that value into the link for a request not being
on the list.
When freeing a skb zero the skb pointer in the request. Use a NULL
value of the skb pointer instead of skb_entry_is_link() for deciding
whether a request has a skb linked to it.
Remove skb_entry_set_link() and open code it instead as it is really
trivial now.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Juergen Gross [Tue, 24 Aug 2021 10:28:07 +0000 (12:28 +0200)]
xen/netfront: don't read data from request on the ring page
In order to avoid a malicious backend being able to influence the local
processing of a request build the request locally first and then copy
it to the ring page. Any reading from the request influencing the
processing in the frontend needs to be done on the local instance.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Juergen Gross [Tue, 24 Aug 2021 10:28:06 +0000 (12:28 +0200)]
xen/netfront: read response from backend only once
In order to avoid problems in case the backend is modifying a response
on the ring page while the frontend has already seen it, just read the
response into a local buffer in one go and then operate on that buffer
only.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Alok Prasad [Tue, 24 Aug 2021 04:02:46 +0000 (04:02 +0000)]
qed: Enable automatic recovery on error condition.
This patch enables automatic recovery by default in case of various
error condition like fw assert , hardware error etc.
This also ensure driver can handle multiple iteration of assertion
conditions.
Signed-off-by: Ariel Elior <aelior@marvell.com>
Signed-off-by: Shai Malin <smalin@marvell.com>
Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
Signed-off-by: Alok Prasad <palok@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gilad Naaman [Thu, 19 Aug 2021 07:17:27 +0000 (10:17 +0300)]
net-next: When a bond have a massive amount of VLANs with IPv6 addresses, performance of changing link state, attaching a VRF, changing an IPv6 address, etc. go down dramtically.
The source of most of the slow down is the `dev_addr_lists.c` module,
which mainatins a linked list of HW addresses.
When using IPv6, this list grows for each IPv6 address added on a
VLAN, since each IPv6 address has a multicast HW address associated with
it.
When performing any modification to the involved links, this list is
traversed many times, often for nothing, all while holding the RTNL
lock.
Instead, this patch adds an auxilliary rbtree which cuts down
traversal time significantly.
Performance can be seen with the following script:
#!/bin/bash
ip netns del test || true 2>/dev/null
ip netns add test
echo 1 | ip netns exec test tee /proc/sys/net/ipv6/conf/all/keep_addr_on_down > /dev/null
set -e
ip -n test link add foo type veth peer name bar
ip -n test link add b1 type bond
ip -n test link add florp type vrf table 10
ip -n test link set bar master b1
ip -n test link set foo up
ip -n test link set bar up
ip -n test link set b1 up
ip -n test link set florp up
VLAN_COUNT=1500
BASE_DEV=b1
echo Creating vlans
ip netns exec test time -p bash -c "for i in \$(seq 1 $VLAN_COUNT);
do ip -n test link add link $BASE_DEV name foo.\$i type vlan id \$i; done"
echo Bringing them up
ip netns exec test time -p bash -c "for i in \$(seq 1 $VLAN_COUNT);
do ip -n test link set foo.\$i up; done"
echo Assiging IPv6 Addresses
ip netns exec test time -p bash -c "for i in \$(seq 1 $VLAN_COUNT);
do ip -n test address add dev foo.\$i 2000::\$i/64; done"
echo Attaching to VRF
ip netns exec test time -p bash -c "for i in \$(seq 1 $VLAN_COUNT);
do ip -n test link set foo.\$i master florp; done"
On an Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz machine, the performance
before the patch is (truncated):
Creating vlans
real 108.35
Bringing them up
real 4.96
Assiging IPv6 Addresses
real 19.22
Attaching to VRF
real 458.84
After the patch:
Creating vlans
real 5.59
Bringing them up
real 5.07
Assiging IPv6 Addresses
real 5.64
Attaching to VRF
real 25.37
Cc: David S. Miller <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Lu Wei <luwei32@huawei.com>
Cc: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Cc: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Gilad Naaman <gnaaman@drivenets.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tang Bin [Mon, 23 Aug 2021 14:10:33 +0000 (22:10 +0800)]
can: mscan: mpc5xxx_can: mpc5xxx_can_probe(): remove useless BUG_ON()
In the function mpc5xxx_can_probe(), the variable 'data' has already
been determined in the above code, so the BUG_ON() in this place is
useless, remove it.
Link: https://lore.kernel.org/r/20210823141033.17876-1-tangbin@cmss.chinamobile.com
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tang Bin [Mon, 23 Aug 2021 11:33:38 +0000 (19:33 +0800)]
can: mscan: mpc5xxx_can: mpc5xxx_can_probe(): use of_device_get_match_data to simplify code
Retrieve OF match data, it's better and cleaner to use
'of_device_get_match_data' over 'of_match_device'.
Link: https://lore.kernel.org/r/20210823113338.3568-4-tangbin@cmss.chinamobile.com
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Lad Prabhakar [Fri, 20 Aug 2021 16:14:49 +0000 (17:14 +0100)]
can: rcar_canfd: rcar_canfd_handle_channel_tx(): fix redundant assignment
Fix redundant assignment of 'priv' to itself in
rcar_canfd_handle_channel_tx().
Fixes:
76e9353a80e9 ("can: rcar_canfd: Add support for RZ/G2L family")
Link: https://lore.kernel.org/r/20210820161449.18169-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Cai Huoqing [Wed, 25 Aug 2021 06:23:41 +0000 (14:23 +0800)]
can: rcar: Kconfig: Add helper dependency on COMPILE_TEST
it's helpful for complie test in other platform(e.g.X86)
Link: https://lore.kernel.org/r/20210825062341.2332-1-caihuoqing@baidu.com
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Kangmin Park [Mon, 23 Aug 2021 10:21:18 +0000 (19:21 +0900)]
net: bridge: change return type of br_handle_ingress_vlan_tunnel
br_handle_ingress_vlan_tunnel() is only referenced in
br_handle_frame(). If br_handle_ingress_vlan_tunnel() is called and
return non-zero value, goto drop in br_handle_frame().
But, br_handle_ingress_vlan_tunnel() always return 0. So, the
routines that check the return value and goto drop has no meaning.
Therefore, change return type of br_handle_ingress_vlan_tunnel() to
void and remove if statement of br_handle_frame().
Signed-off-by: Kangmin Park <l4stpr0gr4m@gmail.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Link: https://lore.kernel.org/r/20210823102118.17966-1-l4stpr0gr4m@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Po-Hsu Lin [Mon, 23 Aug 2021 08:58:54 +0000 (16:58 +0800)]
selftests/net: Use kselftest skip code for skipped tests
There are several test cases in the net directory are still using
exit 0 or exit 1 when they need to be skipped. Use kselftest
framework skip code instead so it can help us to distinguish the
return status.
Criterion to filter out what should be fixed in net directory:
grep -r "exit [01]" -B1 | grep -i skip
This change might cause some false-positives if people are running
these test scripts directly and only checking their return codes,
which will change from 0 to 4. However I think the impact should be
small as most of our scripts here are already using this skip code.
And there will be no such issue if running them with the kselftest
framework.
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Tested-by: Ido Schimmel <idosch@nvidia.com>
Link: https://lore.kernel.org/r/20210823085854.40216-1-po-hsu.lin@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vinicius Costa Gomes [Tue, 27 Jul 2021 03:36:57 +0000 (20:36 -0700)]
igc: Add support for PTP getcrosststamp()
i225 supports PCIe Precision Time Measurement (PTM), allowing us to
support the PTP_SYS_OFFSET_PRECISE ioctl() in the driver via the
getcrosststamp() function.
The easiest way to expose the PTM registers would be to configure the PTM
dialogs to run periodically, but the PTP_SYS_OFFSET_PRECISE ioctl()
semantics are more aligned to using a kind of "one-shot" way of retrieving
the PTM timestamps. But this causes a bit more code to be written: the
trigger registers for the PTM dialogs are not cleared automatically.
i225 can be configured to send "fake" packets with the PTM
information, adding support for handling these types of packets is
left for the future.
PTM improves the accuracy of time synchronization, for example, using
phc2sys, while a simple application is sending packets as fast as
possible. First, without .getcrosststamp():
phc2sys[191.382]: enp4s0 sys offset -959 s2 freq -454 delay 4492
phc2sys[191.482]: enp4s0 sys offset 798 s2 freq +1015 delay 4069
phc2sys[191.583]: enp4s0 sys offset 962 s2 freq +1418 delay 3849
phc2sys[191.683]: enp4s0 sys offset 924 s2 freq +1669 delay 3753
phc2sys[191.783]: enp4s0 sys offset 664 s2 freq +1686 delay 3349
phc2sys[191.883]: enp4s0 sys offset 218 s2 freq +1439 delay 2585
phc2sys[191.983]: enp4s0 sys offset 761 s2 freq +2048 delay 3750
phc2sys[192.083]: enp4s0 sys offset 756 s2 freq +2271 delay 4061
phc2sys[192.183]: enp4s0 sys offset 809 s2 freq +2551 delay 4384
phc2sys[192.283]: enp4s0 sys offset -108 s2 freq +1877 delay 2480
phc2sys[192.383]: enp4s0 sys offset -1145 s2 freq +807 delay 4438
phc2sys[192.484]: enp4s0 sys offset 571 s2 freq +2180 delay 3849
phc2sys[192.584]: enp4s0 sys offset 241 s2 freq +2021 delay 3389
phc2sys[192.684]: enp4s0 sys offset 405 s2 freq +2257 delay 3829
phc2sys[192.784]: enp4s0 sys offset 17 s2 freq +1991 delay 3273
phc2sys[192.884]: enp4s0 sys offset 152 s2 freq +2131 delay 3948
phc2sys[192.984]: enp4s0 sys offset -187 s2 freq +1837 delay 3162
phc2sys[193.084]: enp4s0 sys offset -1595 s2 freq +373 delay 4557
phc2sys[193.184]: enp4s0 sys offset 107 s2 freq +1597 delay 3740
phc2sys[193.284]: enp4s0 sys offset 199 s2 freq +1721 delay 4010
phc2sys[193.385]: enp4s0 sys offset -169 s2 freq +1413 delay 3701
phc2sys[193.485]: enp4s0 sys offset -47 s2 freq +1484 delay 3581
phc2sys[193.585]: enp4s0 sys offset -65 s2 freq +1452 delay 3778
phc2sys[193.685]: enp4s0 sys offset 95 s2 freq +1592 delay 3888
phc2sys[193.785]: enp4s0 sys offset 206 s2 freq +1732 delay 4445
phc2sys[193.885]: enp4s0 sys offset -652 s2 freq +936 delay 2521
phc2sys[193.985]: enp4s0 sys offset -203 s2 freq +1189 delay 3391
phc2sys[194.085]: enp4s0 sys offset -376 s2 freq +955 delay 2951
phc2sys[194.185]: enp4s0 sys offset -134 s2 freq +1084 delay 3330
phc2sys[194.285]: enp4s0 sys offset -22 s2 freq +1156 delay 3479
phc2sys[194.386]: enp4s0 sys offset 32 s2 freq +1204 delay 3602
phc2sys[194.486]: enp4s0 sys offset 122 s2 freq +1303 delay 3731
Statistics for this run (total of 2179 lines), in nanoseconds:
average: -1.12
stdev: 634.80
max: 1551
min: -2215
With .getcrosststamp() via PCIe PTM:
phc2sys[367.859]: enp4s0 sys offset 6 s2 freq +1727 delay 0
phc2sys[367.959]: enp4s0 sys offset -2 s2 freq +1721 delay 0
phc2sys[368.059]: enp4s0 sys offset 5 s2 freq +1727 delay 0
phc2sys[368.160]: enp4s0 sys offset -1 s2 freq +1723 delay 0
phc2sys[368.260]: enp4s0 sys offset -4 s2 freq +1719 delay 0
phc2sys[368.360]: enp4s0 sys offset -5 s2 freq +1717 delay 0
phc2sys[368.460]: enp4s0 sys offset 1 s2 freq +1722 delay 0
phc2sys[368.560]: enp4s0 sys offset -3 s2 freq +1718 delay 0
phc2sys[368.660]: enp4s0 sys offset 5 s2 freq +1725 delay 0
phc2sys[368.760]: enp4s0 sys offset -1 s2 freq +1721 delay 0
phc2sys[368.860]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[368.960]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[369.061]: enp4s0 sys offset 4 s2 freq +1725 delay 0
phc2sys[369.161]: enp4s0 sys offset 1 s2 freq +1724 delay 0
phc2sys[369.261]: enp4s0 sys offset 4 s2 freq +1727 delay 0
phc2sys[369.361]: enp4s0 sys offset 8 s2 freq +1732 delay 0
phc2sys[369.461]: enp4s0 sys offset 7 s2 freq +1733 delay 0
phc2sys[369.561]: enp4s0 sys offset 4 s2 freq +1733 delay 0
phc2sys[369.661]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.761]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.861]: enp4s0 sys offset -5 s2 freq +1725 delay 0
phc2sys[369.961]: enp4s0 sys offset -4 s2 freq +1725 delay 0
phc2sys[370.062]: enp4s0 sys offset 2 s2 freq +1730 delay 0
phc2sys[370.162]: enp4s0 sys offset -7 s2 freq +1721 delay 0
phc2sys[370.262]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.362]: enp4s0 sys offset 1 s2 freq +1726 delay 0
phc2sys[370.462]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.562]: enp4s0 sys offset -1 s2 freq +1724 delay 0
phc2sys[370.662]: enp4s0 sys offset -4 s2 freq +1720 delay 0
phc2sys[370.762]: enp4s0 sys offset -7 s2 freq +1716 delay 0
phc2sys[370.862]: enp4s0 sys offset -2 s2 freq +1719 delay 0
Statistics for this run (total of 2179 lines), in nanoseconds:
average: 0.14
stdev: 5.03
max: 48
min: -27
For reference, the statistics for runs without PCIe congestion show
that the improvements from enabling PTM are less dramatic. For two
runs of 16466 entries:
without PTM: avg -0.04 stdev 10.57 max 39 min -42
with PTM: avg 0.01 stdev 4.20 max 19 min -16
One possible explanation is that when PTM is not enabled, and there's a lot
of traffic in the PCIe fabric, some register reads will take more time
than the others because of congestion on the PCIe fabric.
When PTM is enabled, even if the PTM dialogs take more time to
complete under heavy traffic, the time measurements do not depend on
the time to read the registers.
This was implemented following the i225 EAS version 0.993.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Vinicius Costa Gomes [Tue, 27 Jul 2021 03:36:56 +0000 (20:36 -0700)]
igc: Enable PCIe PTM
Enables PCIe PTM (Precision Time Measurement) support in the igc
driver. Notifies the PCI devices that PCIe PTM should be enabled.
PCIe PTM is similar protocol to PTP (Precision Time Protocol) running
in the PCIe fabric, it allows devices to report time measurements from
their internal clocks and the correlation with the PCIe root clock.
The i225 NIC exposes some registers that expose those time
measurements, those registers will be used, in later patches, to
implement the PTP_SYS_OFFSET_PRECISE ioctl().
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Vinicius Costa Gomes [Tue, 27 Jul 2021 03:36:55 +0000 (20:36 -0700)]
PCI: Add pcie_ptm_enabled()
Add a predicate that returns if PCIe PTM (Precision Time Measurement)
is enabled.
It will only return true if it's enabled in all the ports in the path
from the device to the root.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Vinicius Costa Gomes [Tue, 27 Jul 2021 03:36:54 +0000 (20:36 -0700)]
Revert "PCI: Make pci_enable_ptm() private"
Make pci_enable_ptm() accessible from the drivers.
Exposing this to the driver enables the driver to use the
'ptm_enabled' field of 'pci_dev' to check if PTM is enabled or not.
This reverts commit
ac6c26da29c1 ("PCI: Make pci_enable_ptm() private").
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Jakub Kicinski [Tue, 24 Aug 2021 14:36:56 +0000 (07:36 -0700)]
Merge branch 'ethtool-extend-coalesce-uapi'
Yufeng Mo says:
====================
ethtool: extend coalesce uAPI
In order to support some configuration in coalesce uAPI, this series
extend coalesce uAPI and add support for CQE mode.
Below is some test result with HNS3 driver:
1. old ethtool(ioctl) + new kernel:
estuary:/$ ethtool -c eth0
Coalesce parameters for eth0:
Adaptive RX: on TX: on
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0
rx-usecs: 20
rx-frames: 0
rx-usecs-irq: 0
rx-frames-irq: 0
tx-usecs: 20
tx-frames: 0
tx-usecs-irq: 0
tx-frames-irq: 0
rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0
rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
2. ethtool(netlink with cqe mode) + kernel without cqe mode:
estuary:/$ ethtool -c eth0
Coalesce parameters for eth0:
Adaptive RX: on TX: on
stats-block-usecs: n/a
sample-interval: n/a
pkt-rate-low: n/a
pkt-rate-high: n/a
rx-usecs: 20
rx-frames: 0
rx-usecs-irq: n/a
rx-frames-irq: n/a
tx-usecs: 20
tx-frames: 0
tx-usecs-irq: n/a
tx-frames-irq: n/a
rx-usecs-low: n/a
rx-frame-low: n/a
tx-usecs-low: n/a
tx-frame-low: n/a
rx-usecs-high: 0
rx-frame-high: n/a
tx-usecs-high: 0
tx-frame-high: n/a
CQE mode RX: n/a TX: n/a
3. ethool(netlink with cqe mode) + kernel with cqe mode:
estuary:/$ ethtool -c eth0
Coalesce parameters for eth0:
Adaptive RX: on TX: on
stats-block-usecs: n/a
sample-interval: n/a
pkt-rate-low: n/a
pkt-rate-high: n/a
rx-usecs: 20
rx-frames: 0
rx-usecs-irq: n/a
rx-frames-irq: n/a
tx-usecs: 20
tx-frames: 0
tx-usecs-irq: n/a
tx-frames-irq: n/a
rx-usecs-low: n/a
rx-frame-low: n/a
tx-usecs-low: n/a
tx-frame-low: n/a
rx-usecs-high: 0
rx-frame-high: n/a
tx-usecs-high: 0
tx-frame-high: n/a
CQE mode RX: off TX: off
4. ethool(netlink without cqe mode) + kernel with cqe mode:
estuary:/$ ethtool -c eth0
Coalesce parameters for eth0:
Adaptive RX: on TX: on
stats-block-usecs: n/a
sample-interval: n/a
pkt-rate-low: n/a
pkt-rate-high: n/a
rx-usecs: 20
rx-frames: 0
rx-usecs-irq: n/a
rx-frames-irq: n/a
tx-usecs: 20
tx-frames: 0
tx-usecs-irq: n/a
tx-frames-irq: n/a
rx-usecs-low: n/a
rx-frame-low: n/a
tx-usecs-low: n/a
tx-frame-low: n/a
rx-usecs-high: 0
rx-frame-high: n/a
tx-usecs-high: 0
tx-frame-high: n/a
Change log:
V2 -> V3:
fix some warning on W=1 builds in #2
V1 -> V2:
1. fix compile error using allmodconfig in #2
2. move some property-related modifications from #2 to #1
for better review suggested by Jakub Kicinski.
Change log from RFC:
V3 -> V4:
add document explaining the difference between CQE and EQE
in #1 suggested by Jakub Kicinski.
V2 -> V3:
1. split #1 into adding new parameter and adding new attributes.
2. use NLA_POLICY_MAX(NLA_U8, 1) instead of NLA_U8.
3. modify the description of CQE in Document.
V1 -> V2:
refactor #1 in V1 suggestted by Jakub Kicinski.
====================
Link: https://lore.kernel.org/r/1629444920-25437-1-git-send-email-moyufeng@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Yufeng Mo [Fri, 20 Aug 2021 07:35:20 +0000 (15:35 +0800)]
net: hns3: add ethtool support for CQE/EQE mode configuration
Add support in ethtool for switching EQE/CQE mode.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Yufeng Mo [Fri, 20 Aug 2021 07:35:19 +0000 (15:35 +0800)]
net: hns3: add support for EQE/CQE mode configuration
For device whose version is above V3(include V3), the GL can
select EQE or CQE mode, so adds support for it.
In CQE mode, the coalesced timer will restart when the first new
completion occurs, while in EQE mode, the timer will not restart.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Yufeng Mo [Fri, 20 Aug 2021 07:35:18 +0000 (15:35 +0800)]
ethtool: extend coalesce setting uAPI with CQE mode
In order to support more coalesce parameters through netlink,
add two new parameter kernel_coal and extack for .set_coalesce
and .get_coalesce, then some extra info can return to user with
the netlink API.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Yufeng Mo [Fri, 20 Aug 2021 07:35:17 +0000 (15:35 +0800)]
ethtool: add two coalesce attributes for CQE mode
Currently, there are many drivers who support CQE mode configuration,
some configure it as a fixed when initialized, some provide an
interface to change it by ethtool private flags. In order to make it
more generic, add two new 'ETHTOOL_A_COALESCE_USE_CQE_TX' and
'ETHTOOL_A_COALESCE_USE_CQE_RX' coalesce attributes, then these
parameters can be accessed by ethtool netlink coalesce uAPI.
Also add an new structure kernel_ethtool_coalesce, then the
new parameter can be added into this struct.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Mon, 23 Aug 2021 18:01:35 +0000 (11:01 -0700)]
netdevice: move xdp_rxq within netdev_rx_queue
Both struct netdev_rx_queue and struct xdp_rxq_info are cacheline
aligned. This causes extra padding before and after the xdp_rxq
member. Move the member upfront, so that it's naturally aligned.
Before:
/* size: 256, cachelines: 4, members: 6 */
/* sum members: 160, holes: 1, sum holes: 40 */
/* padding: 56 */
/* paddings: 1, sum paddings: 36 */
/* forced alignments: 1, forced holes: 1, sum forced holes: 40 */
After:
/* size: 192, cachelines: 3, members: 6 */
/* padding: 32 */
/* paddings: 1, sum paddings: 36 */
/* forced alignments: 1 */
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Link: https://lore.kernel.org/r/20210823180135.1153608-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Heiner Kallweit [Tue, 24 Aug 2021 06:23:20 +0000 (08:23 +0200)]
r8169: enable ASPM L0s state
ASPM is disabled completely because we've seen different types of
problems in the past. However it seems these problems occurred with
L1 or L1 sub-states only. On all the chip versions I've seen the
acceptable L0s exit latency is 512ns. This should be short enough not
to cause problems. If the actual L0s exit latency of the PCIe link
is bigger than 512ns then the PCI core will disable L0s anyway.
So let's give it a try and disable L1 and L1 sub-states only.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Yunsheng Lin [Tue, 24 Aug 2021 09:06:49 +0000 (17:06 +0800)]
page_pool: use relaxed atomic for release side accounting
There is no need to synchronize the account updating, so
use the relaxed atomic to avoid some memory barrier in the
data path.
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Tue, 24 Aug 2021 08:30:58 +0000 (09:30 +0100)]
Merge branch 'dsa-sw-bridging'
Vladimir Oltean says:
====================
Plug holes in DSA's software bridging support
Changes in v2:
- Make sure that leaving an unoffloaded bridge works well too
- Remove a set but unused variable
- Tweak a commit message
This series addresses some oddities reported by Alvin while he was
working on the new rtl8365mb driver (a driver which does not implement
bridge offloading for now, and relies on software bridging).
First is that DSA behaves, in the lack of a .port_bridge_join method, as
if the operation succeeds, and does not kick off its internal procedures
for software bridging (the same procedures that were written for indirect
software bridging, meaning bridging with an unoffloaded software LAG).
Second is that even after being patched to treat ports with software
bridging as standalone, we still don't get rid of bridge VLANs, even
though we have code to ignore them, that code manages to get bypassed.
This is in fact a recurring issue which was brought up by Tobias
Waldekranz a while ago, but the solution never made it to the git tree.
After debugging with Florian the last time:
https://patchwork.kernel.org/project/netdevbpf/patch/
20210320225928.2481575-3-olteanv@gmail.com/
I became very concerned about sending these patches to stable kernels.
They are relatively large reworks, and they are only tested properly on
net-next.
A few commands on my test vehicle which has ds->vlan_filtering_is_global
set to true:
| Nothing is committed to hardware when we add VLAN 100 on a standalone
| port
$ ip link add link sw0p2 name sw0p2.100 type vlan id 100
| When a neighbor port joins a VLAN-aware bridge, VLAN filtering gets
| enabled globally on the switch. This replays the VLAN 100 from
| sw0p2.100 and also installs VLAN 1 from the bridge on sw0p0.
$ ip link add br0 type bridge vlan_filtering 1 && ip link set sw0p0 master br0
[ 97.948087] sja1105 spi2.0: Reset switch and programmed static config. Reason: VLAN filtering
[ 97.957989] sja1105 spi2.0: sja1105_bridge_vlan_add: port 2 vlan 100
[ 97.964442] sja1105 spi2.0: sja1105_bridge_vlan_add: port 4 vlan 100
[ 97.971202] device sw0p0 entered promiscuous mode
[ 97.976129] sja1105 spi2.0: sja1105_bridge_vlan_add: port 0 vlan 1
[ 97.982640] sja1105 spi2.0: sja1105_bridge_vlan_add: port 4 vlan 1
| We can see that sw0p2, the standalone port, is now filtering because
| of the bridge
$ ethtool -k sw0p2 | grep vlan
rx-vlan-filter: on [fixed]
| When we make the bridge VLAN-unaware, the 8021q upper sw0p2.100 is
| uncomitted from hardware. The VLANs managed by the bridge still remain
| committed to hardware, because they are managed by the bridge.
$ ip link set br0 type bridge vlan_filtering 0
[ 134.218869] sja1105 spi2.0: Reset switch and programmed static config. Reason: VLAN filtering
[ 134.228913] sja1105 spi2.0: sja1105_bridge_vlan_del: port 2 vlan 100
| And now the standalone port is not filtering anymore.
ethtool -k sw0p2 | grep vlan
rx-vlan-filter: off [fixed]
The same test with .port_bridge_join and .port_bridge_leave commented
out from this driver:
| Not a flinch
$ ip link add link sw0p2 name sw0p2.100 type vlan id 100
$ ip link add br0 type bridge vlan_filtering 1 && ip link set sw0p0 master br0
Warning: dsa_core: Offloading not supported.
$ ethtool -k sw0p2 | grep vlan
rx-vlan-filter: off [fixed]
$ ip link set br0 type bridge vlan_filtering 0
$ ethtool -k sw0p2 | grep vlan
rx-vlan-filter: off [fixed]
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Mon, 23 Aug 2021 21:22:58 +0000 (00:22 +0300)]
net: dsa: let drivers state that they need VLAN filtering while standalone
As explained in commit
e358bef7c392 ("net: dsa: Give drivers the chance
to veto certain upper devices"), the hellcreek driver uses some tricks
to comply with the network stack expectations: it enforces port
separation in standalone mode using VLANs. For untagged traffic,
bridging between ports is prevented by using different PVIDs, and for
VLAN-tagged traffic, it never accepts 8021q uppers with the same VID on
two ports, so packets with one VLAN cannot leak from one port to another.
That is almost fine*, and has worked because hellcreek relied on an
implicit behavior of the DSA core that was changed by the previous
patch: the standalone ports declare the 'rx-vlan-filter' feature as 'on
[fixed]'. Since most of the DSA drivers are actually VLAN-unaware in
standalone mode, that feature was actually incorrectly reflecting the
hardware/driver state, so there was a desire to fix it. This leaves the
hellcreek driver in a situation where it has to explicitly request this
behavior from the DSA framework.
We configure the ports as follows:
- Standalone: 'rx-vlan-filter' is on. An 8021q upper on top of a
standalone hellcreek port will go through dsa_slave_vlan_rx_add_vid
and will add a VLAN to the hardware tables, giving the driver the
opportunity to refuse it through .port_prechangeupper.
- Bridged with vlan_filtering=0: 'rx-vlan-filter' is off. An 8021q upper
on top of a bridged hellcreek port will not go through
dsa_slave_vlan_rx_add_vid, because there will not be any attempt to
offload this VLAN. The driver already disables VLAN awareness, so that
upper should receive the traffic it needs.
- Bridged with vlan_filtering=1: 'rx-vlan-filter' is on. An 8021q upper
on top of a bridged hellcreek port will call dsa_slave_vlan_rx_add_vid,
and can again be vetoed through .port_prechangeupper.
*It is not actually completely fine, because if I follow through
correctly, we can have the following situation:
ip link add br0 type bridge vlan_filtering 0
ip link set lan0 master br0 # lan0 now becomes VLAN-unaware
ip link set lan0 nomaster # lan0 fails to become VLAN-aware again, therefore breaking isolation
This patch fixes that corner case by extending the DSA core logic, based
on this requested attribute, to change the VLAN awareness state of the
switch (port) when it leaves the bridge.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Kurt Kanzenbach <kurt@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Mon, 23 Aug 2021 21:22:57 +0000 (00:22 +0300)]
net: dsa: don't advertise 'rx-vlan-filter' when not needed
There have been multiple independent reports about
dsa_slave_vlan_rx_add_vid being called (and consequently calling the
drivers' .port_vlan_add) when it isn't needed, and sometimes (not
always) causing problems in the process.
Case 1:
mv88e6xxx_port_vlan_prepare is stubborn and only accepts VLANs on
bridged ports. That is understandably so, because standalone mv88e6xxx
ports are VLAN-unaware, and VTU entries are said to be a scarce
resource.
Otherwise said, the following fails lamentably on mv88e6xxx:
ip link add br0 type bridge vlan_filtering 1
ip link set lan3 master br0
ip link add link lan10 name lan10.1 type vlan id 1
[485256.724147] mv88e6085
d0032004.mdio-mii:12: p10: hw VLAN 1 already used by port 3 in br0
RTNETLINK answers: Operation not supported
This has become a worse issue since commit
9b236d2a69da ("net: dsa:
Advertise the VLAN offload netdev ability only if switch supports it").
Up to that point, the driver was returning -EOPNOTSUPP and DSA was
reconverting that error to 0, making the 8021q upper think all is ok
(but obviously the error message was there even prior to this change).
After that change the -EOPNOTSUPP is propagated to vlan_vid_add, and it
is a hard error.
Case 2:
Ports that don't offload the Linux bridge (have a dp->bridge_dev = NULL
because they don't implement .port_bridge_{join,leave}). Understandably,
a standalone port should not offload VLANs either, it should remain VLAN
unaware and any VLAN should be a software VLAN (as long as the hardware
is not quirky, that is).
In fact, dsa_slave_port_obj_add does do the right thing and rejects
switchdev VLAN objects coming from the bridge when that bridge is not
offloaded:
case SWITCHDEV_OBJ_ID_PORT_VLAN:
if (!dsa_port_offloads_bridge_port(dp, obj->orig_dev))
return -EOPNOTSUPP;
err = dsa_slave_vlan_add(dev, obj, extack);
But it seems that the bridge is able to trick us. The __vlan_vid_add
from br_vlan.c has:
/* Try switchdev op first. In case it is not supported, fallback to
* 8021q add.
*/
err = br_switchdev_port_vlan_add(dev, v->vid, flags, extack);
if (err == -EOPNOTSUPP)
return vlan_vid_add(dev, br->vlan_proto, v->vid);
So it says "no, no, you need this VLAN in your life!". And we, naive as
we are, say "oh, this comes from the vlan_vid_add code path, it must be
an 8021q upper, sure, I'll take that". And we end up with that bridge
VLAN installed on our port anyway. But this time, it has the wrong flags:
if the bridge was trying to install VLAN 1 as a pvid/untagged VLAN,
failed via switchdev, retried via vlan_vid_add, we have this comment:
/* This API only allows programming tagged, non-PVID VIDs */
So what we do makes absolutely no sense.
Backtracing a bit, we see the common pattern. We allow the network stack
to think that our standalone ports are VLAN-aware, but they aren't, for
the vast majority of switches. The quirky ones should not dictate the
norm. The dsa_slave_vlan_rx_add_vid and dsa_slave_vlan_rx_kill_vid
methods exist for drivers that need the 'rx-vlan-filter: on' feature in
ethtool -k, which can be due to any of the following reasons:
1. vlan_filtering_is_global = true, and some ports are under a
VLAN-aware bridge while others are standalone, and the standalone
ports would otherwise drop VLAN-tagged traffic. This is described in
commit
061f6a505ac3 ("net: dsa: Add ndo_vlan_rx_{add, kill}_vid
implementation").
2. the ports that are under a VLAN-aware bridge should also set this
feature, for 8021q uppers having a VID not claimed by the bridge.
In this case, the driver will essentially not even know that the VID
is coming from the 8021q layer and not the bridge.
3. Hellcreek. This driver needs it because in standalone mode, it uses
unique VLANs per port to ensure separation. For separation of untagged
traffic, it uses different PVIDs for each port, and for separation of
VLAN-tagged traffic, it never accepts 8021q uppers with the same vid
on two ports.
If a driver does not fall under any of the above 3 categories, there is
no reason why it should advertise the 'rx-vlan-filter' feature, therefore
no reason why it should offload the VLANs added through vlan_vid_add.
This commit fixes the problem by removing the 'rx-vlan-filter' feature
from the slave devices when they operate in standalone mode, and when
they offload a VLAN-unaware bridge.
The way it works is that vlan_vid_add will now stop its processing here:
vlan_add_rx_filter_info:
if (!vlan_hw_filter_capable(dev, proto))
return 0;
So the VLAN will still be saved in the interface's VLAN RX filtering
list, but because it does not declare VLAN filtering in its features,
the 8021q module will return zero without committing that VLAN to
hardware.
This gives the drivers what they want, since it keeps the 8021q VLANs
away from the VLAN table until VLAN awareness is enabled (point at which
the ports are no longer standalone, hence in the mv88e6xxx case, the
check in mv88e6xxx_port_vlan_prepare passes).
Since the issue predates the existence of the hellcreek driver, case 3
will be dealt with in a separate patch.
The main change that this patch makes is to no longer set
NETIF_F_HW_VLAN_CTAG_FILTER unconditionally, but toggle it dynamically
(for most switches, never).
The second part of the patch addresses an issue that the first part
introduces: because the 'rx-vlan-filter' feature is now dynamically
toggled, and our .ndo_vlan_rx_add_vid does not get called when
'rx-vlan-filter' is off, we need to avoid bugs such as the following by
replaying the VLANs from 8021q uppers every time we enable VLAN
filtering:
ip link add link lan0 name lan0.100 type vlan id 100
ip addr add 192.168.100.1/24 dev lan0.100
ping 192.168.100.2 # should work
ip link add br0 type bridge vlan_filtering 0
ip link set lan0 master br0
ping 192.168.100.2 # should still work
ip link set br0 type bridge vlan_filtering 1
ping 192.168.100.2 # should still work but doesn't
As reported by Florian, some drivers look at ds->vlan_filtering in
their .port_vlan_add() implementation. So this patch also makes sure
that ds->vlan_filtering is committed before calling the driver. This is
the reason why it is first committed, then restored on the failure path.
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Reported-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Mon, 23 Aug 2021 21:22:56 +0000 (00:22 +0300)]
net: dsa: properly fall back to software bridging
If the driver does not implement .port_bridge_{join,leave}, then we must
fall back to standalone operation on that port, and trigger the error
path of dsa_port_bridge_join. This sets dp->bridge_dev = NULL.
In turn, having a non-NULL dp->bridge_dev when there is no offloading
support makes the following things go wrong:
- dsa_default_offload_fwd_mark make the wrong decision in setting
skb->offload_fwd_mark. It should set skb->offload_fwd_mark = 0 for
ports that don't offload the bridge, which should instruct the bridge
to forward in software. But this does not happen, dp->bridge_dev is
incorrectly set to point to the bridge, so the bridge is told that
packets have been forwarded in hardware, which they haven't.
- switchdev objects (MDBs, VLANs) should not be offloaded by ports that
don't offload the bridge. Standalone ports should behave as packet-in,
packet-out and the bridge should not be able to manipulate the pvid of
the port, or tag stripping on egress, or ingress filtering. This
should already work fine because dsa_slave_port_obj_add has:
case SWITCHDEV_OBJ_ID_PORT_VLAN:
if (!dsa_port_offloads_bridge_port(dp, obj->orig_dev))
return -EOPNOTSUPP;
err = dsa_slave_vlan_add(dev, obj, extack);
but since dsa_port_offloads_bridge_port works based on dp->bridge_dev,
this is again sabotaging us.
All the above work in case the port has an unoffloaded LAG interface, so
this is well exercised code, we should apply it for plain unoffloaded
bridge ports too.
Reported-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Mon, 23 Aug 2021 21:22:55 +0000 (00:22 +0300)]
net: dsa: don't call switchdev_bridge_port_unoffload for unoffloaded bridge ports
For ports that have a NULL dp->bridge_dev, dsa_port_to_bridge_port()
also returns NULL as expected.
Issue #1 is that we are performing a NULL pointer dereference on brport_dev.
Issue #2 is that these are ports on which switchdev_bridge_port_offload
has not been called, so we should not call switchdev_bridge_port_unoffload
on them either.
Both issues are addressed by checking against a NULL brport_dev in
dsa_port_pre_bridge_leave and exiting early.
Fixes:
2f5dc00f7a3e ("net: bridge: switchdev: let drivers inform which bridge ports are offloaded")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Tue, 24 Aug 2021 08:28:29 +0000 (09:28 +0100)]
Merge branch 'mptcp-refactor'
Mat Martineau says:
====================
mptcp: Refactor ADD_ADDR/RM_ADDR handling
This patch set changes the way MPTCP ADD_ADDR and RM_ADDR options are
handled to improve the reliability of sending and updating address
advertisements. The information used to populate outgoing advertisement
option headers is now stored separately to avoid rare cases where a more
recent request would overwrite something that had not been sent
yet. While the peers would recover from this, it's better to avoid the
problem in the first place.
Patch 1 moves an advertisement option check under a lock so the changes
made in the next several patches will not introduce a race.
Patches 2-4 make sure ADD_ADDR, ADD_ADDR echo, and RM_ADDR options use
separate flags and data.
Patch 5 removes some now-redundant flags.
Patch 6 adds a selftest that confirms the advertisement reliability
improvements.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Yonglong Li [Tue, 24 Aug 2021 01:05:44 +0000 (18:05 -0700)]
selftests: mptcp: add_addr and echo race test
This patch added an extra test for the singal_address_tests() to do the
ADD_ADDR and ADD_ADDR_ECHO race test.
Co-developed-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Yonglong Li <liyonglong@chinatelecom.cn>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
projects / platform / kernel / linux-starfive.git / log