1. 20 4月, 2021 7 次提交
    • H
      net: hns3: cleanup inappropriate spaces in struct hlcgevf_tqp_stats · 8ed64dbe
      Huazhong Tan 提交于
      Modify some inappropriate spaces in comments of struct
      hlcgevf_tqp_stats.
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8ed64dbe
    • H
      net: hns3: remove a duplicate pf reset counting · 1c5a2ba6
      Huazhong Tan 提交于
      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: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c5a2ba6
    • R
      net: xilinx: drivers need/depend on HAS_IOMEM · 46fd4471
      Randy Dunlap 提交于
      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: NRandy Dunlap <rdunlap@infradead.org>
      Reported-by: Nkernel 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: NDavid S. Miller <davem@davemloft.net>
      46fd4471
    • V
      net: enetc: add support for flow control · a8648887
      Vladimir Oltean 提交于
      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: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8648887
    • V
      net: enetc: add a mini driver for the Integrated Endpoint Register Block · e7d48e5f
      Vladimir Oltean 提交于
      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: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e7d48e5f
    • V
      net: enetc: create a common enetc_pf_to_port helper · 87614b93
      Vladimir Oltean 提交于
      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: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87614b93
    • D
      net: mana: Add a driver for Microsoft Azure Network Adapter (MANA) · ca9c54d2
      Dexuan Cui 提交于
      Add a VF driver for Microsoft Azure Network Adapter (MANA) that will be
      available in the future.
      Co-developed-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Co-developed-by: NShachar Raindel <shacharr@microsoft.com>
      Signed-off-by: NShachar Raindel <shacharr@microsoft.com>
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Reviewed-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ca9c54d2
  2. 18 4月, 2021 33 次提交