1. 14 4月, 2021 14 次提交
    • A
      net: ipa: add IPA v4.9 configuration data · e557dc82
      Alex Elder 提交于
      Add support for the SM8350 SoC, which includes IPA version 4.9.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e557dc82
    • A
      dt-bindings: net: qcom,ipa: add support for SM8350 · 15c88e18
      Alex Elder 提交于
      Add support for "qcom,sm8350-ipa", which uses IPA v4.9.
      
      Use "enum" rather than "oneOf/const ..." to specify compatible
      strings, as suggested by Rob Herring.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15c88e18
    • S
      ionic: git_ts_info bit shifters · 1da41aa1
      Shannon Nelson 提交于
      All the uses of HWTSTAMP_FILTER_* values need to be
      bit shifters, not straight values.
      
      v2: fixed subject and added Cc Dan and SoB Allen
      
      Fixes: f8ba81da ("ionic: add ethtool support for PTP")
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NShannon Nelson <snelson@pensando.io>
      Signed-off-by: NAllen Hubbe <allenbh@pensando.io>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1da41aa1
    • L
      ibmvnic: queue reset work in system_long_wq · 870e04ae
      Lijun Pan 提交于
      The reset process for ibmvnic commonly takes multiple seconds, clearly
      making it inappropriate for schedule_work/system_wq. The reason to make
      this change is that ibmvnic's use of the default system-wide workqueue
      for a relatively long-running work item can negatively affect other
      workqueue users. So, queue the relatively slow reset job to the
      system_long_wq.
      Suggested-by: NNathan Lynch <nathanl@linux.ibm.com>
      Signed-off-by: NLijun Pan <lijunp213@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      870e04ae
    • D
      Merge tag 'linux-can-next-for-5.13-20210413' of... · 9fb434bc
      David S. Miller 提交于
      Merge tag 'linux-can-next-for-5.13-20210413' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can-next 2021-04-13
      
      this is a pull request of 14 patches for net-next/master.
      
      The first patch is by Yoshihiro Shimoda and updates the DT bindings
      for the rcar_can driver.
      
      Vincent Mailhol contributes 3 patches that add support for several
      ETAS USB CAN adapters.
      
      The final 10 patches are by me and clean up the peak_usb CAN driver.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9fb434bc
    • Y
      rsi: remove unused including <linux/version.h> · 46568170
      Yang Li 提交于
      Fix the following versioncheck warning:
      ./drivers/net/wireless/rsi/rsi_91x_ps.c: 19 linux/version.h not needed.
      Reported-by: NAbaci Robot <abaci@linux.alibaba.com>
      Signed-off-by: NYang Li <yang.lee@linux.alibaba.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      46568170
    • W
      nfc: st-nci: remove unnecessary label · eba43fac
      wengjianfeng 提交于
      in st_nci_spi_write function, first assign a value to a variable then
      goto exit label. return statement just follow the label and exit label
      just used once, so we should directly return and remove exit label.
      Signed-off-by: Nwengjianfeng <wengjianfeng@yulong.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eba43fac
    • L
      ibmvnic: improve failover sysfs entry · 334c4241
      Lijun Pan 提交于
      The current implementation relies on H_IOCTL call to issue a
      H_SESSION_ERR_DETECTED command to let the hypervisor to send a failover
      signal. However, it may not work if there is no backup device or if
      the vnic is already in error state,
      e.g., "ibmvnic 30000003 env3: rx buffer returned with rc 6".
      Add a last resort, that is to schedule a failover reset via CRQ command.
      Signed-off-by: NLijun Pan <lijunp213@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      334c4241
    • A
      icmp: ICMPV6: pass RFC 8335 reply messages to ping_rcv · 31433202
      Andreas Roeseler 提交于
      The current icmp_rcv function drops all unknown ICMP types, including
      ICMP_EXT_ECHOREPLY (type 43). In order to parse Extended Echo Reply messages, we have
      to pass these packets to the ping_rcv function, which does not do any
      other filtering and passes the packet to the designated socket.
      
      Pass incoming RFC 8335 ICMP Extended Echo Reply packets to the ping_rcv
      handler instead of discarding the packet.
      Signed-off-by: NAndreas Roeseler <andreas.a.roeseler@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31433202
    • D
      Merge branch 'non-platform-devices-of_get_mac_address' · affb05d9
      David S. Miller 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      affb05d9
    • M
      of: net: fix of_get_mac_addr_nvmem() for non-platform devices · f10843e0
      Michael Walle 提交于
      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: NMichael Walle <michael@walle.cc>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f10843e0
    • M
      of: net: pass the dst buffer to of_get_mac_address() · 83216e39
      Michael Walle 提交于
      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: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NMichael Walle <michael@walle.cc>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83216e39
    • R
      net: dsa: mt7530: Add support for EEE features · 40b5d2f1
      René van Dorst 提交于
      This patch adds EEE support.
      Signed-off-by: NRené van Dorst <opensource@vdorst.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40b5d2f1
    • D
      Merge tag 'wireless-drivers-next-2021-04-13' of... · 5fff4c14
      David S. Miller 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      5fff4c14
  2. 13 4月, 2021 26 次提交