+++ /dev/null
-From eb441337c7147514ab45036cadf09c3a71e4ce31 Mon Sep 17 00:00:00 2001
-From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-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 <andriy.shevchenko@linux.intel.com>
-
-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 <andriy.shevchenko@linux.intel.com>
-Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
-Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- 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 <linux/dmi.h>
--#include <linux/gpio.h>
--#include <linux/list.h>
-+
-+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[] = {
--- /dev/null
+From 3a5d12c9be6f30080600c8bacaf310194e37d029 Mon Sep 17 00:00:00 2001
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+Date: Mon, 1 Mar 2021 13:18:18 +0200
+Subject: net: enetc: keep RX ring consumer index in sync with hardware
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+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 <vladimir.oltean@nxp.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 00ff801bb8ce6711e919af4530b6ffa14a22390a Mon Sep 17 00:00:00 2001
+From: "Kevin(Yudong) Yang" <yyd@google.com>
+Date: Wed, 3 Mar 2021 09:43:54 -0500
+Subject: net/mlx4_en: update moderation when config reset
+
+From: Kevin(Yudong) Yang <yyd@google.com>
+
+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 <yyd@google.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Reviewed-by: Neal Cardwell <ncardwell@google.com>
+CC: Tariq Toukan <tariqt@nvidia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 879c348c35bb5fb758dd881d8a97409c1862dae8 Mon Sep 17 00:00:00 2001
+From: Ong Boon Leong <boon.leong.ong@intel.com>
+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 <boon.leong.ong@intel.com>
+
+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 <boon.leong.ong@intel.com>
+Signed-off-by: Ramesh Babu B <ramesh.babu.b@intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From 76c03bf8e2624076b88d93542d78e22d5345c88e Mon Sep 17 00:00:00 2001
+From: Ido Schimmel <idosch@nvidia.com>
+Date: Thu, 4 Mar 2021 10:57:53 +0200
+Subject: nexthop: Do not flush blackhole nexthops when loopback goes down
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+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 <idosch@nvidia.com>
+Reported-by: Donald Sharp <sharpd@nvidia.com>
+Reviewed-by: David Ahern <dsahern@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
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
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
