1. 13 Apr, 2021 5 commits
    • David S. Miller's avatar
      Merge branch 'non-platform-devices-of_get_mac_address' · affb05d9
      David S. Miller authored
      Michael Walle says:
      
      ====================
      of: net: support non-platform devices in of_get_mac_address()
      
      of_get_mac_address() is commonly used to fetch the MAC address
      from the device tree. It also supports reading it from a NVMEM
      provider. But the latter is only possible for platform devices,
      because only platform devices are searched for a matching device
      node.
      
      Add a second method to fetch the NVMEM cell by a device tree node
      instead of a "struct device".
      
      Moreover, the NVMEM subsystem will return dynamically allocated
      data which has to be freed after use. Currently, this is handled
      by allocating a device resource manged buffer to store the MAC
      address. of_get_mac_address() then returns a pointer to this
      buffer. Without a device, this trick is not possible anymore.
      Thus, change the of_get_mac_address() API to have the caller
      supply a buffer.
      
      It was considered to use the network device to attach the buffer
      to, but then the order matters and netdev_register() has to be
      called before of_get_mac_address(). No driver does it this way.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      affb05d9
    • Michael Walle's avatar
      of: net: fix of_get_mac_addr_nvmem() for non-platform devices · f10843e0
      Michael Walle authored
      of_get_mac_address() already supports fetching the MAC address by an
      nvmem provider. But until now, it was just working for platform devices.
      Esp. it was not working for DSA ports and PCI devices. It gets more
      common that PCI devices have a device tree binding since SoCs contain
      integrated root complexes.
      
      Use the nvmem of_* binding to fetch the nvmem cells by a struct
      device_node. We still have to try to read the cell by device first
      because there might be a nvmem_cell_lookup associated with that device.
      Signed-off-by: default avatarMichael Walle <michael@walle.cc>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f10843e0
    • Michael Walle's avatar
      of: net: pass the dst buffer to of_get_mac_address() · 83216e39
      Michael Walle authored
      of_get_mac_address() returns a "const void*" pointer to a MAC address.
      Lately, support to fetch the MAC address by an NVMEM provider was added.
      But this will only work with platform devices. It will not work with
      PCI devices (e.g. of an integrated root complex) and esp. not with DSA
      ports.
      
      There is an of_* variant of the nvmem binding which works without
      devices. The returned data of a nvmem_cell_read() has to be freed after
      use. On the other hand the return of_get_mac_address() points to some
      static data without a lifetime. The trick for now, was to allocate a
      device resource managed buffer which is then returned. This will only
      work if we have an actual device.
      
      Change it, so that the caller of of_get_mac_address() has to supply a
      buffer where the MAC address is written to. Unfortunately, this will
      touch all drivers which use the of_get_mac_address().
      
      Usually the code looks like:
      
        const char *addr;
        addr = of_get_mac_address(np);
        if (!IS_ERR(addr))
          ether_addr_copy(ndev->dev_addr, addr);
      
      This can then be simply rewritten as:
      
        of_get_mac_address(np, ndev->dev_addr);
      
      Sometimes is_valid_ether_addr() is used to test the MAC address.
      of_get_mac_address() already makes sure, it just returns a valid MAC
      address. Thus we can just test its return code. But we have to be
      careful if there are still other sources for the MAC address before the
      of_get_mac_address(). In this case we have to keep the
      is_valid_ether_addr() call.
      
      The following coccinelle patch was used to convert common cases to the
      new style. Afterwards, I've manually gone over the drivers and fixed the
      return code variable: either used a new one or if one was already
      available use that. Mansour Moufid, thanks for that coccinelle patch!
      
      <spml>
      @A@
      identifier x;
      expression y, z;
      @@
      - x = of_get_mac_address(y);
      + x = of_get_mac_address(y, z);
        <...
      - ether_addr_copy(z, x);
        ...>
      
      @@
      identifier a.x;
      @@
      - if (<+... x ...+>) {}
      
      @@
      identifier a.x;
      @@
        if (<+... x ...+>) {
            ...
        }
      - else {}
      
      @@
      identifier a.x;
      expression e;
      @@
      - if (<+... x ...+>@e)
      -     {}
      - else
      + if (!(e))
            {...}
      
      @@
      expression x, y, z;
      @@
      - x = of_get_mac_address(y, z);
      + of_get_mac_address(y, z);
        ... when != x
      </spml>
      
      All drivers, except drivers/net/ethernet/aeroflex/greth.c, were
      compile-time tested.
      Suggested-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarMichael Walle <michael@walle.cc>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      83216e39
    • René van Dorst's avatar
      net: dsa: mt7530: Add support for EEE features · 40b5d2f1
      René van Dorst authored
      This patch adds EEE support.
      Signed-off-by: default avatarRené van Dorst <opensource@vdorst.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40b5d2f1
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-next-2021-04-13' of... · 5fff4c14
      David S. Miller authored
      Merge tag 'wireless-drivers-next-2021-04-13' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
      
      Kalle Valo says:
      
      ====================
      wireless-drivers-next patches for v5.13
      
      First set of patches for v5.13. I have been offline for a couple of
      and I have a smaller pull request this time. The next one will be
      bigger. Nothing really special standing out.
      
      ath11k
      
      * add initial support for QCN9074, but not enabled yet due to firmware problems
      
      * enable radar detection for 160MHz secondary segment
      
      * handle beacon misses in station mode
      
      rtw88
      
      * 8822c: support firmware crash dump
      
      mt7601u
      
      * enable TDLS support
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5fff4c14
  2. 12 Apr, 2021 23 commits
  3. 11 Apr, 2021 12 commits
    • David S. Miller's avatar
      Merge branch 'ipa-next' · 5b489fea
      David S. Miller authored
      Alex Elder says:
      
      ====================
      net: ipa: support two more platforms
      
      This series adds IPA support for two more Qualcomm SoCs.
      
      The first patch updates the DT binding to add compatible strings.
      
      The second temporarily disables checksum offload support for IPA
      version 4.5 and above.  Changes are required to the RMNet driver
      to support the "inline" checksum offload used for IPA v4.5+, and
      once those are present this capability will be enabled for IPA.
      
      The third and fourth patches add configuration data for IPA versions
      4.5 (used for the SDX55 SoC) and 4.11 (used for the SD7280 SoC).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b489fea
    • Alex Elder's avatar
      net: ipa: add IPA v4.11 configuration data · 927c5043
      Alex Elder authored
      Add support for the SC7280 SoC, which includes IPA version 4.11.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      927c5043
    • Alex Elder's avatar
      net: ipa: add IPA v4.5 configuration data · fbb763e7
      Alex Elder authored
      Add support for the SDX55 SoC, which includes IPA version 4.5.
      
      Starting with IPA v4.5, a few of the memory regions have a different
      number of "canary" values; update comments in the where the region
      identifers are defined to accurately reflect that.
      
      I'll note three differences in SDX55 versus the other two existing
      platforms (SDM845 and SC7180):
        - SDX55 uses a 32-bit Linux kernel
        - SDX55 has four interconnects rather than three
        - SDX55 uses IPA v4.5, which uses inline checksum offload
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbb763e7
    • Alex Elder's avatar
      net: ipa: disable checksum offload for IPA v4.5+ · c88c34fc
      Alex Elder authored
      Checksum offload for IPA v4.5+ is implemented differently, using
      "inline" offload (which uses a common header format for both upload
      and download offload).
      
      The IPA hardware must be programmed to enable MAP checksum offload,
      but the RMNet driver is responsible for interpreting checksum
      metadata supplied with messages.
      
      Currently, the RMNet driver does not support inline checksum offload.
      This support is imminent, but until it is available, do not allow
      newer versions of IPA to specify checksum offload for endpoints.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c88c34fc
    • Alex Elder's avatar
      dt-bindings: net: qcom,ipa: add some compatible strings · c3264fee
      Alex Elder authored
      Add existing supported platform "qcom,sc7180-ipa" to the set of IPA
      compatible strings.  Also add newly-supported "qcom,sdx55-ipa",
      "qcom,sc7280-ipa".
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3264fee
    • Qiheng Lin's avatar
      ehea: add missing MODULE_DEVICE_TABLE · 95291ced
      Qiheng Lin authored
      This patch adds missing MODULE_DEVICE_TABLE definition which generates
      correct modalias for automatic loading of this driver when it is built
      as an external module.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarQiheng Lin <linqiheng@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      95291ced
    • David S. Miller's avatar
      Merge branch 'veth-gro' · 23cfa4d4
      David S. Miller authored
      Paolo Abeni  says:
      
      ====================
      veth: allow GRO even without XDP
      
      This series allows the user-space to enable GRO/NAPI on a veth
      device even without attaching an XDP program.
      
      It does not change the default veth behavior (no NAPI, no GRO),
      except that the GRO feature bit on top of this series will be
      effectively off by default on veth devices. Note that currently
      the GRO bit is on by default, but GRO never takes place in
      absence of XDP.
      
      On top of this series, setting the GRO feature bit enables NAPI
      and allows the GRO to take place. The TSO features on the peer
      device are preserved.
      
      The main goal is improving UDP forwarding performances for
      containers in a typical virtual network setup:
      
      (container) veth -> veth peer -> bridge/ovs -> vxlan -> NIC
      
      Enabling the NAPI threaded mode, GRO the NETIF_F_GRO_UDP_FWD
      feature on the veth peer improves the UDP stream performance
      with not void netfilter configuration by 2x factor with no
      measurable overhead for TCP traffic: some heuristic ensures
      that TCP will not go through the additional NAPI/GRO layer.
      
      Some self-tests are added to check the expected behavior in
      the default configuration, with XDP and with plain GRO enabled.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      23cfa4d4
    • Paolo Abeni's avatar
      self-tests: add veth tests · 1c3cadbe
      Paolo Abeni authored
      Add some basic veth tests, that verify the expected flags and
      aggregation with different setups (default, xdp, etc...)
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c3cadbe
    • Paolo Abeni's avatar
      veth: refine napi usage · 47e550e0
      Paolo Abeni authored
      After the previous patch, when enabling GRO, locally generated
      TCP traffic experiences some measurable overhead, as it traverses
      the GRO engine without any chance of aggregation.
      
      This change refine the NAPI receive path admission test, to avoid
      unnecessary GRO overhead in most scenarios, when GRO is enabled
      on a veth peer.
      
      Only skbs that are eligible for aggregation enter the GRO layer,
      the others will go through the traditional receive path.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      47e550e0
    • Paolo Abeni's avatar
      veth: allow enabling NAPI even without XDP · d3256efd
      Paolo Abeni authored
      Currently the veth device has the GRO feature bit set, even if
      no GRO aggregation is possible with the default configuration,
      as the veth device does not hook into the GRO engine.
      
      Flipping the GRO feature bit from user-space is a no-op, unless
      XDP is enabled. In such scenario GRO could actually take place, but
      TSO is forced to off on the peer device.
      
      This change allow user-space to really control the GRO feature, with
      no need for an XDP program.
      
      The GRO feature bit is now cleared by default - so that there are no
      user-visible behavior changes with the default configuration.
      
      When the GRO bit is set, the per-queue NAPI instances are initialized
      and registered. On xmit, when napi instances are available, we try
      to use them.
      
      Some additional checks are in place to ensure we initialize/delete NAPIs
      only when needed in case of overlapping XDP and GRO configuration
      changes.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d3256efd
    • Paolo Abeni's avatar
      veth: use skb_orphan_partial instead of skb_orphan · c75fb320
      Paolo Abeni authored
      As described by commit 9c4c3252 ("skbuff: preserve sock
      reference when scrubbing the skb."), orphaning a skb
      in the TX path will cause OoO.
      
      Let's use skb_orphan_partial() instead of skb_orphan(), so
      that we keep the sk around for queue's selection sake and we
      still avoid the problem fixed with commit 4bf9ffa0 ("veth:
      Orphan skb before GRO")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c75fb320
    • David S. Miller's avatar
      Merge branch 'ethtool-eeprom' · 7dc85b59
      David S. Miller authored
      Moshe Shemesh says:
      
      ====================
      ethtool: Extend module EEPROM dump API
      
      Ethtool supports module EEPROM dumps via the `ethtool -m <dev>` command.
      But in current state its functionality is limited - offset and length
      parameters, which are used to specify a linear desired region of EEPROM
      data to dump, is not enough, considering emergence of complex module
      EEPROM layouts such as CMIS 4.0.
      Moreover, CMIS 4.0 extends the amount of pages that may be accessible by
      introducing another parameter for page addressing - banks.
      
      Besides, currently module EEPROM is represented as a chunk of
      concatenated pages, where lower 128 bytes of all pages, except page 00h,
      are omitted. Offset and length are used to address parts of this fake
      linear memory. But in practice drivers, which implement
      get_module_info() and get_module_eeprom() ethtool ops still calculate
      page number and set I2C address on their own.
      
      This series tackles these issues by adding ethtool op, which allows to
      pass page number, bank number and I2C address in addition to offset and
      length parameters to the driver, adds corresponding netlink
      infrastructure and implements the new interface in mlx5 driver.
      
      This allows to extend userspace 'ethtool -m' CLI by adding new
      parameters - page, bank and i2c. New command line format:
       ethtool -m <dev> [hex on|off] [raw on|off] [offset N] [length N] [page N] [bank N] [i2c N]
      
      The consequence of this series is a possibility to dump arbitrary EEPROM
      page at a time, in contrast to dumps of concatenated pages. Therefore,
      offset and length change their semantics and may be used only to specify
      a part of data within half page boundary, which size is currently limited
      to 128 bytes.
      
      As for drivers that support legacy get_module_info() and
      get_module_eeprom() pair, the series addresses it by implementing a
      fallback mechanism. As mentioned earlier, such drivers derive a page
      number from 'global' offset, so this can be done vice versa without
      their involvement thanks to standardization. If kernel netlink handler
      of 'ethtool -m' command detects that new ethtool op is not supported by
      the driver, it calculates offset from given page number and page offset
      and calls old ndos, if they are available.
      ====================
      
      \Signed-off-by: David S. Miller <davem@davemloft.net>
      7dc85b59