1. 19 Apr, 2021 19 commits
    • DENG Qingfang's avatar
      net: ethernet: mediatek: fix a typo bug in flow offloading · 6ecaf81d
      DENG Qingfang authored
      Issue was traffic problems after a while with increased ping times if
      flow offload is active. It turns out that key_offset with cookie is
      needed in rhashtable_params but was re-assigned to head_offset.
      Fix the assignment.
      
      Fixes: 502e84e2 ("net: ethernet: mtk_eth_soc: add flow offloading support")
      Signed-off-by: default avatarDENG Qingfang <dqfext@gmail.com>
      Tested-by: default avatarFrank Wunderlich <frank-w@public-files.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ecaf81d
    • David S. Miller's avatar
      Merge branch 'hns3-next' · 32c1fdb5
      David S. Miller authored
      Huazhong Tan says:
      
      ====================
      net: hns3: misc updates for -next
      
      This series includes some misc updates for the HNS3 ethernet driver.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32c1fdb5
    • Huazhong Tan's avatar
      net: hns3: change the value of the SEPARATOR_VALUE macro in hclgevf_main.c · e407efdd
      Huazhong Tan authored
      The SEPARATOR_VALUE macro is used as separator when getting
      the register value, but the value of this macro is different
      between pf and vf, it is a bit confusing for the user, so
      synchronize the value of vf with pf.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e407efdd
    • Huazhong Tan's avatar
      net: hns3: cleanup inappropriate spaces in struct hlcgevf_tqp_stats · 8ed64dbe
      Huazhong Tan authored
      Modify some inappropriate spaces in comments of struct
      hlcgevf_tqp_stats.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ed64dbe
    • Huazhong Tan's avatar
      net: hns3: remove a duplicate pf reset counting · 1c5a2ba6
      Huazhong Tan authored
      When enter suspend mode the counter of pf reset will be increased
      twice, since both hclge_prepare_general() and hclge_prepare_wait()
      increase this counter. So remove the duplicate counting in
      hclge_prepare_general().
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c5a2ba6
    • Randy Dunlap's avatar
      net: xilinx: drivers need/depend on HAS_IOMEM · 46fd4471
      Randy Dunlap authored
      kernel test robot reports build errors in 3 Xilinx ethernet drivers.
      They all use ioremap functions that are only available when HAS_IOMEM
      is set/enabled. If it is not enabled, they all have build errors,
      so make these 3 drivers depend on HAS_IOMEM.
      
      ld: drivers/net/ethernet/xilinx/xilinx_emaclite.o: in function `xemaclite_of_probe':
      xilinx_emaclite.c:(.text+0x9fc): undefined reference to `devm_ioremap_resource'
      
      ld: drivers/net/ethernet/xilinx/xilinx_axienet_main.o: in function `axienet_probe':
      xilinx_axienet_main.c:(.text+0x942): undefined reference to `devm_ioremap_resource'
      
      ld: drivers/net/ethernet/xilinx/ll_temac_main.o: in function `temac_probe':
      ll_temac_main.c:(.text+0x1283): undefined reference to `devm_platform_ioremap_resource_byname'
      ld: ll_temac_main.c:(.text+0x13ad): undefined reference to `devm_of_iomap'
      ld: ll_temac_main.c:(.text+0x162e): undefined reference to `devm_platform_ioremap_resource'
      
      Fixes: 8a3b7a25 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Cc: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
      Cc: Gary Guo <gary@garyguo.net>
      Cc: Zhang Changzhong <zhangchangzhong@huawei.com>
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: stable@vger.kernel.org
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      46fd4471
    • David S. Miller's avatar
      Merge branch 'enetc-flow-control' · 6ed33c13
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Flow control for NXP ENETC
      
      This patch series contains logic for enabling the lossless mode on the
      RX rings of the ENETC, and the PAUSE thresholds on the internal FIFO
      memory.
      
      During testing it was found that, with the default FIFO configuration,
      a sender which isn't persuaded by our PAUSE frames and keeps sending
      will cause some MAC RX frame errors. To mitigate this, we need to ensure
      that the FIFO never runs completely full, so we need to fix up a setting
      that was supposed to be configured well out of reset. Unfortunately this
      requires the addition of a new mini-driver.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ed33c13
    • Vladimir Oltean's avatar
      net: enetc: add support for flow control · a8648887
      Vladimir Oltean authored
      In the ENETC receive path, a frame received by the MAC is first stored
      in a 256KB 'FIFO' memory, then transferred to DRAM when enqueuing it to
      the RX ring. The FIFO is a shared resource for all ENETC ports, but
      every port keeps track of its own memory utilization, on RX and on TX.
      
      There is a setting for RX rings through which they can either operate in
      'lossy' mode (where the lack of a free buffer causes an immediate
      discard of the frame) or in 'lossless' mode (where the lack of a free
      buffer in the ring makes the frame stay longer in the FIFO).
      
      In turn, when the memory utilization of the FIFO exceeds a certain
      margin, the MAC can be configured to emit PAUSE frames.
      
      There is enough FIFO memory to buffer up to 3 MTU-sized frames per RX
      port while not jeopardizing the other use cases (jumbo frames), and
      also not consume bytes from the port TX allocations. Also, 3 MTU-sized
      frames worth of memory is enough to ensure zero loss for 64 byte packets
      at 1G line rate.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarClaudiu Manoil <claudiu.manoil@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8648887
    • Vladimir Oltean's avatar
      arm64: dts: ls1028a: declare the Integrated Endpoint Register Block node · b764dc6c
      Vladimir Oltean authored
      Add a node describing the address in the SoC memory space for the IERB.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b764dc6c
    • Vladimir Oltean's avatar
      net: enetc: add a mini driver for the Integrated Endpoint Register Block · e7d48e5f
      Vladimir Oltean authored
      The NXP ENETC is a 4-port Ethernet controller which 'smells' to
      operating systems like 4 distinct PCIe PFs with SR-IOV, each PF having
      its own driver instance, but in fact there are some hardware resources
      which are shared between all ports, like for example the 256 KB SRAM
      FIFO between the MACs and the Host Transfer Agent which DMAs frames to
      DRAM.
      
      To hide the stuff that cannot be neatly exposed per port, the hardware
      designers came up with this idea of having a dedicated register block
      which is supposed to be populated by the bootloader, and contains
      everything configuration-related: MAC addresses, FIFO partitioning, etc.
      
      When a port is reset using PCIe Function Level Reset, its defaults are
      transferred from the IERB configuration. Most of the time, the settings
      made through the IERB are read-only in the port's memory space (if they
      are even visible), so they cannot be modified at runtime.
      
      Linux doesn't have any advanced FIFO partitioning requirements at all,
      but when reading through the hardware manual, it became clear that, even
      though there are many good 'recommendations' for default values, many of
      them were not actually put in practice on LS1028A. So we end up with a
      default configuration that:
      
      (a) does not have enough TX and RX byte credits to support the max MTU
          of 9600 (which the Linux driver claims already) properly (at full speed)
      (b) allows the FIFO to be overrun with RX traffic, potentially
          overwriting internal data structures.
      
      The last part sounds a bit catastrophic, but it isn't. Frames are
      supposed to transit the FIFO for a very short time, but they can
      actually accumulate there under 2 conditions:
      
      (a) there is very severe congestion on DRAM memory, or
      (b) the RX rings visible to the operating system were configured for
          lossless operation, and they just ran out of free buffers to copy
          the frame to. This is what is used to put backpressure onto the MAC
          with flow control.
      
      So since ENETC has not supported flow control thus far, RX FIFO overruns
      were never seen with Linux. But with the addition of flow control, we
      should configure some registers to prevent this from happening. What we
      are trying to protect against are bad actors which continue to send us
      traffic despite the fact that we have signaled a PAUSE condition. Of
      course we can't be lossless in that case, but it is best to configure
      the FIFO to do tail dropping rather than letting it overrun.
      
      So in a nutshell, this driver is a fixup for all the IERB default values
      that should have been but aren't.
      
      The IERB configuration needs to be done _before_ the PFs are enabled.
      So every PF searches for the presence of the "fsl,ls1028a-enetc-ierb"
      node in the device tree, and if it finds it, it "registers" with the
      IERB, which means that it requests the IERB to fix up its default
      values. This is done through -EPROBE_DEFER. The IERB driver is part of
      the fsl_enetc module, but is technically a platform driver, since the
      IERB is a good old fashioned MMIO region, as opposed to ENETC ports
      which pretend to be PCIe devices.
      
      The driver was already configuring ENETC_PTXMBAR (FIFO allocation for
      TX) because due to an omission, TXMBAR is a read/write register in the
      PF memory space. But the manual is quite clear that the formula for this
      should depend upon the TX byte credits (TXBCR). In turn, the TX byte
      credits are only readable/writable through the IERB. So if we want to
      ensure that the TXBCR register also has a value that is correct and in
      line with TXMBAR, there is simply no way this can be done from the PF
      driver, access to the IERB is needed.
      
      I could have modified U-Boot to fix up the IERB values, but that is
      quite undesirable, as old U-Boot versions are likely to be floating
      around for quite some time from now.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e7d48e5f
    • Vladimir Oltean's avatar
      dt-bindings: net: fsl: enetc: add the IERB documentation · 4ac7acc6
      Vladimir Oltean authored
      Mention the required compatible string and base address for the
      Integrated Endpoint Register Block node.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4ac7acc6
    • Vladimir Oltean's avatar
      net: enetc: create a common enetc_pf_to_port helper · 87614b93
      Vladimir Oltean authored
      Even though ENETC interfaces are exposed as individual PCIe PFs with
      their own driver instances, the ENETC is still fundamentally a
      multi-port Ethernet controller, and some parts of the IP take a port
      number (as can be seen in the PSFP implementation).
      
      Create a common helper that can be used outside of the TSN code for
      retrieving the ENETC port number based on the PF number. This is only
      correct for LS1028A, the only Linux-capable instantiation of ENETC thus
      far.
      
      Note that ENETC port 3 is PF 6. The TSN code did not care about this
      because ENETC port 3 does not support TSN, so the wrong mapping done by
      enetc_get_port for PF 6 could have never been hit.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      87614b93
    • Gustavo A. R. Silva's avatar
      ethtool: ioctl: Fix out-of-bounds warning in store_link_ksettings_for_user() · c1d9e34e
      Gustavo A. R. Silva authored
      Fix the following out-of-bounds warning:
      
      net/ethtool/ioctl.c:492:2: warning: 'memcpy' offset [49, 84] from the object at 'link_usettings' is out of the bounds of referenced subobject 'base' with type 'struct ethtool_link_settings' at offset 0 [-Warray-bounds]
      
      The problem is that the original code is trying to copy data into a
      some struct members adjacent to each other in a single call to
      memcpy(). This causes a legitimate compiler warning because memcpy()
      overruns the length of &link_usettings.base. Fix this by directly
      using &link_usettings and _from_ as destination and source addresses,
      instead.
      
      This helps with the ongoing efforts to globally enable -Warray-bounds
      and get us closer to being able to tighten the FORTIFY_SOURCE routines
      on memcpy().
      
      Link: https://github.com/KSPP/linux/issues/109Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarGustavo A. R. Silva <gustavoars@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c1d9e34e
    • Dexuan Cui's avatar
      net: mana: Add a driver for Microsoft Azure Network Adapter (MANA) · ca9c54d2
      Dexuan Cui authored
      Add a VF driver for Microsoft Azure Network Adapter (MANA) that will be
      available in the future.
      Co-developed-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Co-developed-by: default avatarShachar Raindel <shacharr@microsoft.com>
      Signed-off-by: default avatarShachar Raindel <shacharr@microsoft.com>
      Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
      Reviewed-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ca9c54d2
    • Taehee Yoo's avatar
      mld: remove unnecessary prototypes · 83c1ca25
      Taehee Yoo authored
      Some prototypes are unnecessary, so delete it.
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      83c1ca25
    • David S. Miller's avatar
      Merge branch 'nh-flushing' · c589fa10
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      nexthop: Support large scale nexthop flushing
      
      Patch #1 fixes a day-one bug in the nexthop code and allows "ip nexthop
      flush" to work correctly with large number of nexthops that do not fit
      in a single-part dump.
      
      Patch #2 adds a test case.
      
      Targeting at net-next since this use case never worked, the flow is
      pretty obscure and such a large number of nexthops is unlikely to be
      used in any real-world scenario.
      
      Tested with fib_nexthops.sh:
      
      Tests passed: 219
      Tests failed:   0
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c589fa10
    • Ido Schimmel's avatar
      selftests: fib_nexthops: Test large scale nexthop flushing · bf5eb67d
      Ido Schimmel authored
      Test that all the nexthops are flushed when a multi-part nexthop dump is
      required for the flushing.
      
      Without previous patch:
      
       # ./fib_nexthops.sh
       TEST: Large scale nexthop flushing                                  [FAIL]
      
      With previous patch:
      
       # ./fib_nexthops.sh
       TEST: Large scale nexthop flushing                                  [ OK ]
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf5eb67d
    • Ido Schimmel's avatar
      nexthop: Restart nexthop dump based on last dumped nexthop identifier · 9e46fb65
      Ido Schimmel authored
      Currently, a multi-part nexthop dump is restarted based on the number of
      nexthops that have been dumped so far. This can result in a lot of
      nexthops not being dumped when nexthops are simultaneously deleted:
      
       # ip nexthop | wc -l
       65536
       # ip nexthop flush
       Dump was interrupted and may be inconsistent.
       Flushed 36040 nexthops
       # ip nexthop | wc -l
       29496
      
      Instead, restart the dump based on the nexthop identifier (fixed number)
      of the last successfully dumped nexthop:
      
       # ip nexthop | wc -l
       65536
       # ip nexthop flush
       Dump was interrupted and may be inconsistent.
       Flushed 65536 nexthops
       # ip nexthop | wc -l
       0
      Reported-by: default avatarMaksym Yaremchuk <maksymy@nvidia.com>
      Tested-by: default avatarMaksym Yaremchuk <maksymy@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9e46fb65
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-next-2021-04-18' of... · 56aa7b21
      David S. Miller authored
      Merge tag 'wireless-drivers-next-2021-04-18' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
      
      Kalle Valo says:
      
      ====================
      wireless-drivers-next patches for v5.13
      
      Second set of patches for v5.13. A lot of iwlwifi and mt76 patches
      this time, and also smaller features and fixes all over.
      
      mt76
      
      * mt7915/mt7615 decapsulation offload support
      
      * threaded NAPI support
      
      * new device IDs
      
      * mt7921 device reset support
      
      * rx timestamp support
      
      iwlwifi
      
      * passive scan support for 6GHz
      
      * new hardware support
      
      wilc1000
      
      * CRC support for SPI bus
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      56aa7b21
  2. 18 Apr, 2021 15 commits
  3. 17 Apr, 2021 6 commits