From: Greg Kroah-Hartman Date: Fri, 12 Mar 2021 12:41:37 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v4.4.262~104 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=d1c0c382ea7934e2e97e2e849ca36e19bfdad5fa;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: net-enetc-keep-rx-ring-consumer-index-in-sync-with-hardware.patch net-mlx4_en-update-moderation-when-config-reset.patch net-stmmac-fix-incorrect-dma-channel-intr-enable-setting-of-eqos-v4.10.patch nexthop-do-not-flush-blackhole-nexthops-when-loopback-goes-down.patch --- diff --git a/queue-5.4/gpio-pca953x-set-irq-type-when-handle-intel-galileo-gen-2.patch b/queue-5.4/gpio-pca953x-set-irq-type-when-handle-intel-galileo-gen-2.patch deleted file mode 100644 index c3401060208..00000000000 --- a/queue-5.4/gpio-pca953x-set-irq-type-when-handle-intel-galileo-gen-2.patch +++ /dev/null @@ -1,136 +0,0 @@ -From eb441337c7147514ab45036cadf09c3a71e4ce31 Mon Sep 17 00:00:00 2001 -From: Andy Shevchenko -Date: Thu, 25 Feb 2021 18:33:20 +0200 -Subject: gpio: pca953x: Set IRQ type when handle Intel Galileo Gen 2 -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -From: Andy Shevchenko - -commit eb441337c7147514ab45036cadf09c3a71e4ce31 upstream. - -The commit 0ea683931adb ("gpio: dwapb: Convert driver to using the -GPIO-lib-based IRQ-chip") indeliberately made a regression on how -IRQ line from GPIO I²C expander is handled. I.e. it reveals that -the quirk for Intel Galileo Gen 2 misses the part of setting IRQ type -which previously was predefined by gpio-dwapb driver. Now, we have to -reorganize the approach to call necessary parts, which can be done via -ACPI_GPIO_QUIRK_ABSOLUTE_NUMBER quirk. - -Without this fix and with above mentioned change the kernel hangs -on the first IRQ event with: - - gpio gpiochip3: Persistence not supported for GPIO 1 - irq 32, desc: 62f8fb50, depth: 0, count: 0, unhandled: 0 - ->handle_irq(): 41c7b0ab, handle_bad_irq+0x0/0x40 - ->irq_data.chip(): e03f1e72, 0xc2539218 - ->action(): 0ecc7e6f - ->action->handler(): 8a3db21e, irq_default_primary_handler+0x0/0x10 - IRQ_NOPROBE set - unexpected IRQ trap at vector 20 - -Fixes: ba8c90c61847 ("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2") -Depends-on: 0ea683931adb ("gpio: dwapb: Convert driver to using the GPIO-lib-based IRQ-chip") -Signed-off-by: Andy Shevchenko -Acked-by: Mika Westerberg -Reviewed-by: Linus Walleij -Signed-off-by: Greg Kroah-Hartman ---- - drivers/gpio/gpio-pca953x.c | 78 ++++++++++++-------------------------------- - 1 file changed, 23 insertions(+), 55 deletions(-) - ---- a/drivers/gpio/gpio-pca953x.c -+++ b/drivers/gpio/gpio-pca953x.c -@@ -110,8 +110,29 @@ MODULE_DEVICE_TABLE(i2c, pca953x_id); - #ifdef CONFIG_GPIO_PCA953X_IRQ - - #include --#include --#include -+ -+static const struct acpi_gpio_params pca953x_irq_gpios = { 0, 0, true }; -+ -+static const struct acpi_gpio_mapping pca953x_acpi_irq_gpios[] = { -+ { "irq-gpios", &pca953x_irq_gpios, 1, ACPI_GPIO_QUIRK_ABSOLUTE_NUMBER }, -+ { } -+}; -+ -+static int pca953x_acpi_get_irq(struct device *dev) -+{ -+ int ret; -+ -+ ret = devm_acpi_dev_add_driver_gpios(dev, pca953x_acpi_irq_gpios); -+ if (ret) -+ dev_warn(dev, "can't add GPIO ACPI mapping\n"); -+ -+ ret = acpi_dev_gpio_irq_get_by(ACPI_COMPANION(dev), "irq-gpios", 0); -+ if (ret < 0) -+ return ret; -+ -+ dev_info(dev, "ACPI interrupt quirk (IRQ %d)\n", ret); -+ return ret; -+} - - static const struct dmi_system_id pca953x_dmi_acpi_irq_info[] = { - { -@@ -130,59 +151,6 @@ static const struct dmi_system_id pca953 - }, - {} - }; -- --#ifdef CONFIG_ACPI --static int pca953x_acpi_get_pin(struct acpi_resource *ares, void *data) --{ -- struct acpi_resource_gpio *agpio; -- int *pin = data; -- -- if (acpi_gpio_get_irq_resource(ares, &agpio)) -- *pin = agpio->pin_table[0]; -- return 1; --} -- --static int pca953x_acpi_find_pin(struct device *dev) --{ -- struct acpi_device *adev = ACPI_COMPANION(dev); -- int pin = -ENOENT, ret; -- LIST_HEAD(r); -- -- ret = acpi_dev_get_resources(adev, &r, pca953x_acpi_get_pin, &pin); -- acpi_dev_free_resource_list(&r); -- if (ret < 0) -- return ret; -- -- return pin; --} --#else --static inline int pca953x_acpi_find_pin(struct device *dev) { return -ENXIO; } --#endif -- --static int pca953x_acpi_get_irq(struct device *dev) --{ -- int pin, ret; -- -- pin = pca953x_acpi_find_pin(dev); -- if (pin < 0) -- return pin; -- -- dev_info(dev, "Applying ACPI interrupt quirk (GPIO %d)\n", pin); -- -- if (!gpio_is_valid(pin)) -- return -EINVAL; -- -- ret = gpio_request(pin, "pca953x interrupt"); -- if (ret) -- return ret; -- -- ret = gpio_to_irq(pin); -- -- /* When pin is used as an IRQ, no need to keep it requested */ -- gpio_free(pin); -- -- return ret; --} - #endif - - static const struct acpi_device_id pca953x_acpi_ids[] = { diff --git a/queue-5.4/net-enetc-keep-rx-ring-consumer-index-in-sync-with-hardware.patch b/queue-5.4/net-enetc-keep-rx-ring-consumer-index-in-sync-with-hardware.patch new file mode 100644 index 00000000000..f76a7f26c4f --- /dev/null +++ b/queue-5.4/net-enetc-keep-rx-ring-consumer-index-in-sync-with-hardware.patch @@ -0,0 +1,242 @@ +From 3a5d12c9be6f30080600c8bacaf310194e37d029 Mon Sep 17 00:00:00 2001 +From: Vladimir Oltean +Date: Mon, 1 Mar 2021 13:18:18 +0200 +Subject: net: enetc: keep RX ring consumer index in sync with hardware + +From: Vladimir Oltean + +commit 3a5d12c9be6f30080600c8bacaf310194e37d029 upstream. + +The RX rings have a producer index owned by hardware, where newly +received frame buffers are placed, and a consumer index owned by +software, where newly allocated buffers are placed, in expectation of +hardware being able to place frame data in them. + +Hardware increments the producer index when a frame is received, however +it is not allowed to increment the producer index to match the consumer +index (RBCIR) since the ring can hold at most RBLENR[LENGTH]-1 received +BDs. Whenever the producer index matches the value of the consumer +index, the ring has no unprocessed received frames and all BDs in the +ring have been initialized/prepared by software, i.e. hardware owns all +BDs in the ring. + +The code uses the next_to_clean variable to keep track of the producer +index, and the next_to_use variable to keep track of the consumer index. + +The RX rings are seeded from enetc_refill_rx_ring, which is called from +two places: + +1. initially the ring is seeded until full with enetc_bd_unused(rx_ring), + i.e. with 511 buffers. This will make next_to_clean=0 and next_to_use=511: + +.ndo_open +-> enetc_open + -> enetc_setup_bdrs + -> enetc_setup_rxbdr + -> enetc_refill_rx_ring + +2. then during the data path processing, it is refilled with 16 buffers + at a time: + +enetc_msix +-> napi_schedule + -> enetc_poll + -> enetc_clean_rx_ring + -> enetc_refill_rx_ring + +There is just one problem: the initial seeding done during .ndo_open +updates just the producer index (ENETC_RBPIR) with 0, and the software +next_to_clean and next_to_use variables. Notably, it will not update the +consumer index to make the hardware aware of the newly added buffers. + +Wait, what? So how does it work? + +Well, the reset values of the producer index and of the consumer index +of a ring are both zero. As per the description in the second paragraph, +it means that the ring is full of buffers waiting for hardware to put +frames in them, which by coincidence is almost true, because we have in +fact seeded 511 buffers into the ring. + +But will the hardware attempt to access the 512th entry of the ring, +which has an invalid BD in it? Well, no, because in order to do that, it +would have to first populate the first 511 entries, and the NAPI +enetc_poll will kick in by then. Eventually, after 16 processed slots +have become available in the RX ring, enetc_clean_rx_ring will call +enetc_refill_rx_ring and then will [ finally ] update the consumer index +with the new software next_to_use variable. From now on, the +next_to_clean and next_to_use variables are in sync with the producer +and consumer ring indices. + +So the day is saved, right? Well, not quite. Freeing the memory +allocated for the rings is done in: + +enetc_close +-> enetc_clear_bdrs + -> enetc_clear_rxbdr + -> this just disables the ring +-> enetc_free_rxtx_rings + -> enetc_free_rx_ring + -> sets next_to_clean and next_to_use to 0 + +but again, nothing is committed to the hardware producer and consumer +indices (yay!). The assumption is that the ring is disabled, so the +indices don't matter anyway, and it's the responsibility of the "open" +code path to set those up. + +.. Except that the "open" code path does not set those up properly. + +While initially, things almost work, during subsequent enetc_close -> +enetc_open sequences, we have problems. To be precise, the enetc_open +that is subsequent to enetc_close will again refill the ring with 511 +entries, but it will leave the consumer index untouched. Untouched +means, of course, equal to the value it had before disabling the ring +and draining the old buffers in enetc_close. + +But as mentioned, enetc_setup_rxbdr will at least update the producer +index though, through this line of code: + + enetc_rxbdr_wr(hw, idx, ENETC_RBPIR, 0); + +so at this stage we'll have: + +next_to_clean=0 (in hardware 0) +next_to_use=511 (in hardware we'll have the refill index prior to enetc_close) + +Again, the next_to_clean and producer index are in sync and set to +correct values, so the driver manages to limp on. Eventually, 16 ring +entries will be consumed by enetc_poll, and the savior +enetc_clean_rx_ring will come and call enetc_refill_rx_ring, and then +update the hardware consumer ring based upon the new next_to_use. + +So.. it works? +Well, by coincidence, it almost does, but there's a circumstance where +enetc_clean_rx_ring won't be there to save us. If the previous value of +the consumer index was 15, there's a problem, because the NAPI poll +sequence will only issue a refill when 16 or more buffers have been +consumed. + +It's easiest to illustrate this with an example: + +ip link set eno0 up +ip addr add 192.168.100.1/24 dev eno0 +ping 192.168.100.1 -c 20 # ping this port from another board +ip link set eno0 down +ip link set eno0 up +ping 192.168.100.1 -c 20 # ping it again from the same other board + +One by one: + +1. ip link set eno0 up +-> calls enetc_setup_rxbdr: + -> calls enetc_refill_rx_ring(511 buffers) + -> next_to_clean=0 (in hw 0) + -> next_to_use=511 (in hw 0) + +2. ping 192.168.100.1 -c 20 # ping this port from another board +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=1 next_to_clean 0 (in hw 1) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=2 next_to_clean 1 (in hw 2) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=3 next_to_clean 2 (in hw 3) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=4 next_to_clean 3 (in hw 4) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=5 next_to_clean 4 (in hw 5) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=6 next_to_clean 5 (in hw 6) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=7 next_to_clean 6 (in hw 7) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=8 next_to_clean 7 (in hw 8) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=9 next_to_clean 8 (in hw 9) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=10 next_to_clean 9 (in hw 10) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=11 next_to_clean 10 (in hw 11) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=12 next_to_clean 11 (in hw 12) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=13 next_to_clean 12 (in hw 13) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=14 next_to_clean 13 (in hw 14) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=15 next_to_clean 14 (in hw 15) next_to_use 511 (in hw 0) +enetc_clean_rx_ring: enetc_refill_rx_ring(16) increments next_to_use by 16 (mod 512) and writes it to hw +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=0 next_to_clean 15 (in hw 16) next_to_use 15 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=1 next_to_clean 16 (in hw 17) next_to_use 15 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=2 next_to_clean 17 (in hw 18) next_to_use 15 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=3 next_to_clean 18 (in hw 19) next_to_use 15 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=4 next_to_clean 19 (in hw 20) next_to_use 15 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=5 next_to_clean 20 (in hw 21) next_to_use 15 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=6 next_to_clean 21 (in hw 22) next_to_use 15 (in hw 15) + +20 packets transmitted, 20 packets received, 0% packet loss + +3. ip link set eno0 down +enetc_free_rx_ring: next_to_clean 0 (in hw 22), next_to_use 0 (in hw 15) + +4. ip link set eno0 up +-> calls enetc_setup_rxbdr: + -> calls enetc_refill_rx_ring(511 buffers) + -> next_to_clean=0 (in hw 0) + -> next_to_use=511 (in hw 15) + +5. ping 192.168.100.1 -c 20 # ping it again from the same other board +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=1 next_to_clean 0 (in hw 1) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=2 next_to_clean 1 (in hw 2) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=3 next_to_clean 2 (in hw 3) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=4 next_to_clean 3 (in hw 4) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=5 next_to_clean 4 (in hw 5) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=6 next_to_clean 5 (in hw 6) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=7 next_to_clean 6 (in hw 7) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=8 next_to_clean 7 (in hw 8) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=9 next_to_clean 8 (in hw 9) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=10 next_to_clean 9 (in hw 10) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=11 next_to_clean 10 (in hw 11) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=12 next_to_clean 11 (in hw 12) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=13 next_to_clean 12 (in hw 13) next_to_use 511 (in hw 15) +enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=14 next_to_clean 13 (in hw 14) next_to_use 511 (in hw 15) + +20 packets transmitted, 12 packets received, 40% packet loss + +And there it dies. No enetc_refill_rx_ring (because cleaned_cnt must be equal +to 15 for that to happen), no nothing. The hardware enters the condition where +the producer (14) + 1 is equal to the consumer (15) index, which makes it +believe it has no more free buffers to put packets in, so it starts discarding +them: + +ip netns exec ns0 ethtool -S eno0 | grep -v ': 0' +NIC statistics: + Rx ring 0 discarded frames: 8 + +Summarized, if the interface receives between 16 and 32 (mod 512) frames +and then there is a link flap, then the port will eventually die with no +way to recover. If it receives less than 16 (mod 512) frames, then the +initial NAPI poll [ before the link flap ] will not update the consumer +index in hardware (it will remain zero) which will be ok when the buffers +are later reinitialized. If more than 32 (mod 512) frames are received, +the initial NAPI poll has the chance to refill the ring twice, updating +the consumer index to at least 32. So after the link flap, the consumer +index is still wrong, but the post-flap NAPI poll gets a chance to +refill the ring once (because it passes through cleaned_cnt=15) and +makes the consumer index be again back in sync with next_to_use. + +The solution to this problem is actually simple, we just need to write +next_to_use into the hardware consumer index at enetc_open time, which +always brings it back in sync after an initial buffer seeding process. + +The simpler thing would be to put the write to the consumer index into +enetc_refill_rx_ring directly, but there are issues with the MDIO +locking: in the NAPI poll code we have the enetc_lock_mdio() taken from +top-level and we use the unlocked enetc_wr_reg_hot, whereas in +enetc_open, the enetc_lock_mdio() is not taken at the top level, but +instead by each individual enetc_wr_reg, so we are forced to put an +additional enetc_wr_reg in enetc_setup_rxbdr. Better organization of +the code is left as a refactoring exercise. + +Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers") +Signed-off-by: Vladimir Oltean +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/freescale/enetc/enetc.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/net/ethernet/freescale/enetc/enetc.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc.c +@@ -1162,6 +1162,8 @@ static void enetc_setup_rxbdr(struct ene + rx_ring->idr = hw->reg + ENETC_SIRXIDR; + + enetc_refill_rx_ring(rx_ring, enetc_bd_unused(rx_ring)); ++ /* update ENETC's consumer index */ ++ enetc_rxbdr_wr(hw, idx, ENETC_RBCIR, rx_ring->next_to_use); + + /* enable ring */ + enetc_rxbdr_wr(hw, idx, ENETC_RBMR, rbmr); diff --git a/queue-5.4/net-mlx4_en-update-moderation-when-config-reset.patch b/queue-5.4/net-mlx4_en-update-moderation-when-config-reset.patch new file mode 100644 index 00000000000..801ea604f0b --- /dev/null +++ b/queue-5.4/net-mlx4_en-update-moderation-when-config-reset.patch @@ -0,0 +1,80 @@ +From 00ff801bb8ce6711e919af4530b6ffa14a22390a Mon Sep 17 00:00:00 2001 +From: "Kevin(Yudong) Yang" +Date: Wed, 3 Mar 2021 09:43:54 -0500 +Subject: net/mlx4_en: update moderation when config reset + +From: Kevin(Yudong) Yang + +commit 00ff801bb8ce6711e919af4530b6ffa14a22390a upstream. + +This patch fixes a bug that the moderation config will not be +applied when calling mlx4_en_reset_config. For example, when +turning on rx timestamping, mlx4_en_reset_config() will be called, +causing the NIC to forget previous moderation config. + +This fix is in phase with a previous fix: +commit 79c54b6bbf06 ("net/mlx4_en: Fix TX moderation info loss +after set_ringparam is called") + +Tested: Before this patch, on a host with NIC using mlx4, run +netserver and stream TCP to the host at full utilization. +$ sar -I SUM 1 + INTR intr/s +14:03:56 sum 48758.00 + +After rx hwtstamp is enabled: +$ sar -I SUM 1 +14:10:38 sum 317771.00 +We see the moderation is not working properly and issued 7x more +interrupts. + +After the patch, and turned on rx hwtstamp, the rate of interrupts +is as expected: +$ sar -I SUM 1 +14:52:11 sum 49332.00 + +Fixes: 79c54b6bbf06 ("net/mlx4_en: Fix TX moderation info loss after set_ringparam is called") +Signed-off-by: Kevin(Yudong) Yang +Reviewed-by: Eric Dumazet +Reviewed-by: Neal Cardwell +CC: Tariq Toukan +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2 +- + drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 ++ + drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 + + 3 files changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c ++++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c +@@ -47,7 +47,7 @@ + #define EN_ETHTOOL_SHORT_MASK cpu_to_be16(0xffff) + #define EN_ETHTOOL_WORD_MASK cpu_to_be32(0xffffffff) + +-static int mlx4_en_moderation_update(struct mlx4_en_priv *priv) ++int mlx4_en_moderation_update(struct mlx4_en_priv *priv) + { + int i, t; + int err = 0; +--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c ++++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c +@@ -3657,6 +3657,8 @@ int mlx4_en_reset_config(struct net_devi + en_err(priv, "Failed starting port\n"); + } + ++ if (!err) ++ err = mlx4_en_moderation_update(priv); + out: + mutex_unlock(&mdev->state_lock); + kfree(tmp); +--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h ++++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h +@@ -797,6 +797,7 @@ void mlx4_en_ptp_overflow_check(struct m + #define DEV_FEATURE_CHANGED(dev, new_features, feature) \ + ((dev->features & feature) ^ (new_features & feature)) + ++int mlx4_en_moderation_update(struct mlx4_en_priv *priv); + int mlx4_en_reset_config(struct net_device *dev, + struct hwtstamp_config ts_config, + netdev_features_t new_features); diff --git a/queue-5.4/net-stmmac-fix-incorrect-dma-channel-intr-enable-setting-of-eqos-v4.10.patch b/queue-5.4/net-stmmac-fix-incorrect-dma-channel-intr-enable-setting-of-eqos-v4.10.patch new file mode 100644 index 00000000000..5abf439030e --- /dev/null +++ b/queue-5.4/net-stmmac-fix-incorrect-dma-channel-intr-enable-setting-of-eqos-v4.10.patch @@ -0,0 +1,57 @@ +From 879c348c35bb5fb758dd881d8a97409c1862dae8 Mon Sep 17 00:00:00 2001 +From: Ong Boon Leong +Date: Wed, 3 Mar 2021 20:38:40 +0530 +Subject: net: stmmac: fix incorrect DMA channel intr enable setting of EQoS v4.10 + +From: Ong Boon Leong + +commit 879c348c35bb5fb758dd881d8a97409c1862dae8 upstream. + +We introduce dwmac410_dma_init_channel() here for both EQoS v4.10 and +above which use different DMA_CH(n)_Interrupt_Enable bit definitions for +NIE and AIE. + +Fixes: 48863ce5940f ("stmmac: add DMA support for GMAC 4.xx") +Signed-off-by: Ong Boon Leong +Signed-off-by: Ramesh Babu B +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 19 ++++++++++++++++++- + 1 file changed, 18 insertions(+), 1 deletion(-) + +--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c ++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c +@@ -116,6 +116,23 @@ static void dwmac4_dma_init_channel(void + ioaddr + DMA_CHAN_INTR_ENA(chan)); + } + ++static void dwmac410_dma_init_channel(void __iomem *ioaddr, ++ struct stmmac_dma_cfg *dma_cfg, u32 chan) ++{ ++ u32 value; ++ ++ /* common channel control register config */ ++ value = readl(ioaddr + DMA_CHAN_CONTROL(chan)); ++ if (dma_cfg->pblx8) ++ value = value | DMA_BUS_MODE_PBL; ++ ++ writel(value, ioaddr + DMA_CHAN_CONTROL(chan)); ++ ++ /* Mask interrupts by writing to CSR7 */ ++ writel(DMA_CHAN_INTR_DEFAULT_MASK_4_10, ++ ioaddr + DMA_CHAN_INTR_ENA(chan)); ++} ++ + static void dwmac4_dma_init(void __iomem *ioaddr, + struct stmmac_dma_cfg *dma_cfg, int atds) + { +@@ -462,7 +479,7 @@ const struct stmmac_dma_ops dwmac4_dma_o + const struct stmmac_dma_ops dwmac410_dma_ops = { + .reset = dwmac4_dma_reset, + .init = dwmac4_dma_init, +- .init_chan = dwmac4_dma_init_channel, ++ .init_chan = dwmac410_dma_init_channel, + .init_rx_chan = dwmac4_dma_init_rx_chan, + .init_tx_chan = dwmac4_dma_init_tx_chan, + .axi = dwmac4_dma_axi, diff --git a/queue-5.4/nexthop-do-not-flush-blackhole-nexthops-when-loopback-goes-down.patch b/queue-5.4/nexthop-do-not-flush-blackhole-nexthops-when-loopback-goes-down.patch new file mode 100644 index 00000000000..5499d428062 --- /dev/null +++ b/queue-5.4/nexthop-do-not-flush-blackhole-nexthops-when-loopback-goes-down.patch @@ -0,0 +1,81 @@ +From 76c03bf8e2624076b88d93542d78e22d5345c88e Mon Sep 17 00:00:00 2001 +From: Ido Schimmel +Date: Thu, 4 Mar 2021 10:57:53 +0200 +Subject: nexthop: Do not flush blackhole nexthops when loopback goes down + +From: Ido Schimmel + +commit 76c03bf8e2624076b88d93542d78e22d5345c88e upstream. + +As far as user space is concerned, blackhole nexthops do not have a +nexthop device and therefore should not be affected by the +administrative or carrier state of any netdev. + +However, when the loopback netdev goes down all the blackhole nexthops +are flushed. This happens because internally the kernel associates +blackhole nexthops with the loopback netdev. + +This behavior is both confusing to those not familiar with kernel +internals and also diverges from the legacy API where blackhole IPv4 +routes are not flushed when the loopback netdev goes down: + + # ip route add blackhole 198.51.100.0/24 + # ip link set dev lo down + # ip route show 198.51.100.0/24 + blackhole 198.51.100.0/24 + +Blackhole IPv6 routes are flushed, but at least user space knows that +they are associated with the loopback netdev: + + # ip -6 route show 2001:db8:1::/64 + blackhole 2001:db8:1::/64 dev lo metric 1024 pref medium + +Fix this by only flushing blackhole nexthops when the loopback netdev is +unregistered. + +Fixes: ab84be7e54fc ("net: Initial nexthop code") +Signed-off-by: Ido Schimmel +Reported-by: Donald Sharp +Reviewed-by: David Ahern +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/nexthop.c | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +--- a/net/ipv4/nexthop.c ++++ b/net/ipv4/nexthop.c +@@ -1065,7 +1065,7 @@ out: + + /* rtnl */ + /* remove all nexthops tied to a device being deleted */ +-static void nexthop_flush_dev(struct net_device *dev) ++static void nexthop_flush_dev(struct net_device *dev, unsigned long event) + { + unsigned int hash = nh_dev_hashfn(dev->ifindex); + struct net *net = dev_net(dev); +@@ -1077,6 +1077,10 @@ static void nexthop_flush_dev(struct net + if (nhi->fib_nhc.nhc_dev != dev) + continue; + ++ if (nhi->reject_nh && ++ (event == NETDEV_DOWN || event == NETDEV_CHANGE)) ++ continue; ++ + remove_nexthop(net, nhi->nh_parent, NULL); + } + } +@@ -1794,11 +1798,11 @@ static int nh_netdev_event(struct notifi + switch (event) { + case NETDEV_DOWN: + case NETDEV_UNREGISTER: +- nexthop_flush_dev(dev); ++ nexthop_flush_dev(dev, event); + break; + case NETDEV_CHANGE: + if (!(dev_get_flags(dev) & (IFF_RUNNING | IFF_LOWER_UP))) +- nexthop_flush_dev(dev); ++ nexthop_flush_dev(dev, event); + break; + case NETDEV_CHANGEMTU: + info_ext = ptr; diff --git a/queue-5.4/series b/queue-5.4/series index 7c920273a0b..c0f0730128a 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -8,7 +8,6 @@ net-avoid-infinite-loop-in-mpls_gso_segment-when-mpls_hlen-0.patch gpiolib-acpi-allow-to-find-gpioint-resource-by-name-and-index.patch sh_eth-fix-trscer-mask-for-sh771x.patch can-skb-can_skb_set_owner-fix-ref-counting-if-socket-was-closed-before-setting-skb-ownership.patch -gpio-pca953x-set-irq-type-when-handle-intel-galileo-gen-2.patch can-flexcan-assert-frz-bit-in-flexcan_chip_freeze.patch can-flexcan-enable-rx-fifo-after-frz-halt-valid.patch can-flexcan-invoke-flexcan_chip_freeze-to-enter-freeze-mode.patch @@ -26,3 +25,7 @@ mount-fix-mounting-of-detached-mounts-onto-targets-that-reside-on-shared-mounts. cifs-return-proper-error-code-in-statfs-2.patch revert-mm-slub-consider-rest-of-partial-list-if-acquire_slab-fails.patch net-enetc-don-t-overwrite-the-rss-indirection-table-when-initializing.patch +net-enetc-keep-rx-ring-consumer-index-in-sync-with-hardware.patch +net-mlx4_en-update-moderation-when-config-reset.patch +net-stmmac-fix-incorrect-dma-channel-intr-enable-setting-of-eqos-v4.10.patch +nexthop-do-not-flush-blackhole-nexthops-when-loopback-goes-down.patch