1. 18 Dec, 2019 16 commits
  2. 17 Dec, 2019 24 commits
    • Florian Fainelli's avatar
      net: dsa: Make PHYLINK related function static again · 8ae67496
      Florian Fainelli authored
      Commit 77373d49 ("net: dsa: Move the phylink driver calls into
      port.c") moved and exported a bunch of symbols, but they are not used
      outside of net/dsa/port.c at the moment, so no reason to export them.
      Reported-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Acked-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ae67496
    • Jon Maloy's avatar
      tipc: don't send gap blocks in ACK messages · b7ffa045
      Jon Maloy authored
      In the commit referred to below we eliminated sending of the 'gap'
      indicator in regular ACK messages, reserving this to explicit NACK
      ditto.
      
      Unfortunately we missed to also eliminate building of the 'gap block'
      area in ACK messages. This area is meant to report gaps in the
      received packet sequence following the initial gap, so that lost
      packets can be retransmitted earlier and received out-of-sequence
      packets can be released earlier. However, the interpretation of those
      blocks is dependent on a complete and correct sequence of gaps and
      acks. Hence, when the initial gap indicator is missing a single gap
      block will be interpreted as an acknowledgment of all preceding
      packets. This may lead to packets being released prematurely from the
      sender's transmit queue, with easily predicatble consequences.
      
      We now fix this by not building any gap block area if there is no
      initial gap to report.
      
      Fixes: commit 02288248 ("tipc: eliminate gap indicator from ACK messages")
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7ffa045
    • David S. Miller's avatar
      Merge branch 'stmmac-dwc-qos-ACPI-device-support' · 2b2d81a6
      David S. Miller authored
      Ajay Gupta says:
      
      ====================
      net: stmmac: dwc-qos: ACPI device support
      
      Version 3 of patches have fixes for comments from Jakub Kicinski.
      
      These two changes are needed to enable ACPI based devices to use stmmac
      driver. First patch is to use generic device api (device_*) instead of
      device tree based api (of_*). Second patch avoids clock and reset accesses
      for Tegra ACPI based devices. ACPI interface will be used to access clock
      and reset for Tegra ACPI devices in later patches.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b2d81a6
    • Ajay Gupta's avatar
      net: stmmac: dwc-qos: avoid clk and reset for acpi device · 1d4605e0
      Ajay Gupta authored
      There are no clocks, resets or gpios referenced by Tegra ACPI
      device so don't access clocks, resets or gpios interface with
      ACPI device.
      
      Clocks, resets and GPIOs for ACPI devices will be handled via
      ACPI interface.
      Signed-off-by: default avatarAjay Gupta <ajayg@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d4605e0
    • Ajay Gupta's avatar
      net: stmmac: dwc-qos: use generic device api · b59c43e0
      Ajay Gupta authored
      Use generic device api so that driver can work both with DT
      or ACPI based devices.
      Signed-off-by: default avatarAjay Gupta <ajayg@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b59c43e0
    • David S. Miller's avatar
      Merge branch 'dwmac-mediatek-add-more-support-for-RMII' · ce2b5a3a
      David S. Miller authored
      Biao Huang says:
      
      ====================
      net-next: stmmac: dwmac-mediatek: add more support for RMII
      
      changes in v2:
       PATCH 1/2 net-next: stmmac: mediatek: add more support for RMII
              As Andrew's comments, add the "rmii_internal" clock to the list of clocks.
      
       PATCH 2/2 net-next: dt-binding: dwmac-mediatek: add more description for RMII
              document the "rmii_internal" clock in dt-bindings
              rewrite the sample dts in dt-bindings.
      
      v1:
      This series is for support RMII when MT2712 SoC provides the reference clock.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce2b5a3a
    • Biao Huang's avatar
      net-next: dt-binding: dwmac-mediatek: add more description for RMII · 882007ed
      Biao Huang authored
      MT2712 SoC can provide RMII reference clock,
      so add corresponding description in dt-binding.
      Signed-off-by: default avatarBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      882007ed
    • Biao Huang's avatar
      net-next: stmmac: mediatek: add more support for RMII · 71a55a23
      Biao Huang authored
      MT2712 SoC can provide the rmii reference clock, and the clock
      will output from TXC pin only, which means ref_clk pin of external
      PHY should connect to TXC pin in this case.
      Add corresponding clock and timing settings.
      Signed-off-by: default avatarBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71a55a23
    • David S. Miller's avatar
      Merge branch 'improve-clause-45-support-in-phylink' · 4e133f76
      David S. Miller authored
      Russell King says:
      
      ====================
      improve clause 45 support in phylink
      
      These three patches improve the clause 45 support in phylink, fixing
      some corner cases that have been noticed with the addition of SFP+
      NBASE-T modules, but are actually a little more wisespread than I
      initially realised.
      
      The first issue was spotted with a NBASE-T PHY on a SFP+ module plugged
      into a mvneta platform. When these PHYs are not operating in USXGMII
      mode, but are in a single-lane Serdes mode, they will switch between
      one of several different PHY interface modes.
      
      If we call the MAC validate() function with the current PHY interface
      mode, we will restrict the supported and advertising masks to the link
      modes that the current PHY interface mode supports. For example, if we
      determine that we want to start the PHY with an interface mode of
      2500BASE-X, then this setup will restrict the advertisement and
      supported masks to 2.5G speed link modes.
      
      What we actually want for these PHYs is to allow them to support any
      link modes that the PHY supports _and_ the MAC is also capable of
      supporting. Without knowing the details of the PHY interface modes that
      may be used, we can do this by using PHY_INTERFACE_MODE_NA to validate
      and restrict the link modes to any that the MAC supports.
      
      mvpp2 with the 88X3310 PHY avoids this problem, because the validate()
      implementation allows all MAC supported speeds not only for
      PHY_INTERFACE_MODE_NA, but also for XAUI and 10GKR modes.
      
      The first patch addresses this; current MAC drivers should continue to
      work as-is, but there will be a follow-on patch to fixup at least
      mvpp2.
      
      The second issue addresses a very similar problem that occurs when
      trying to use ethtool to alter the advertisement mask - we call
      the MAC validate() function with the current interface mode, the
      current support and requested advertisement masks. This immediately
      restricts the advertisement in the same way as the above.
      
      This patch series addresses both issues, although the patches are not
      in the above order.
      
      v2: fix patch 3 missing 1G link modes for SGMII and RGMII interface
          modes.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e133f76
    • Russell King's avatar
      net: mvpp2: update mvpp2 validate() implementation · ef8e0b80
      Russell King authored
      Fix up the mvpp2 validate implementation to adopt the same behaviour as
      mvneta:
      - only allow the link modes that the specified PHY interface mode
        supports with the exception of 1000base-X and 2500base-X.
      - use the basex helper to deal with SFP modules that can be switched
        between 1000base-X vs 2500base-X.
      
      This gives consistent behaviour between mvneta and mvpp2.
      
      This commit depends on "net: phylink: extend clause 45 PHY validation
      workaround" so is not marked for backporting to stable kernels.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: default avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef8e0b80
    • Russell King's avatar
      net: phylink: extend clause 45 PHY validation workaround · df3f57ac
      Russell King authored
      Commit e45d1f52 ("net: phylink: support Clause 45 PHYs on SFP+
      modules") added a workaround to support clause 45 PHYs which
      dynamically switch their interface mode on SFP+ modules.  This was
      implemented by validating the PHYs supported/advertising using
      PHY_INTERFACE_MODE_NA, rather than the specific interface mode that
      we attached the PHY with.
      
      However, we already have a situation where phylink is used to connect
      a Marvell 88X3310 PHY which also behaves in exactly the same way, but
      which seemingly doesn't need this.  The reason seems to be that the
      mvpp2 driver sets a whole bunch of link modes for
      PHY_INTERFACE_MODE_10GKR down to 10Mb/s, despite 10GBASE-R not actually
      supporting anything but 10Gb/s speeds.
      
      When testing with drivers that (correctly) take the mvneta approach,
      where the validate() method only returns what can be supported /
      advertised for the specified link mode, we find that Clause 45 PHYs do
      not behave as we expect: their advertisement is restricted to what
      the current link will support, rather than what the PHY supports
      through its dynamic switching.
      
      Extend this workaround to all such cases; if we have a Clause 45 PHY
      attaching via any means, except in USXGMII, XAUI and RXAUI which are
      all unable to support this dynamic switching or have other solutions
      to it, then we need to validate using PHY_INTERFACE_MODE_NA.
      
      This should allow mvpp2 to switch to a more conformant validate()
      implementation.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df3f57ac
    • Russell King's avatar
      net: phylink: improve clause 45 PHY ksettings_set implementation · 5d57c327
      Russell King authored
      While testing ethtool with the Methode DM7052 module, it was noticed
      that attempting to set the advertising mask results in the mask being
      truncated to the support offered by the currently chosen PHY interface
      mode.
      
      When a PHY dynamically changes the PHY interface mode, limiting the
      advertising mask in this way is not correct - if the PHY happened to
      negotiate 10GBASE-T, and selected 10GBASE-R as the host interface, we
      don't want to restrict the advertisement to just 10GBASE-* modes.
      
      Rework setting the advertisement to take account of this; do not pass
      the requested advertisement through phylink_validate(), but rely on
      the advertisement restriction (supported mask) set when the PHY was
      initially setup.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5d57c327
    • David S. Miller's avatar
      Merge branch 'WireGuard-CI-and-housekeeping' · 6f6dded1
      David S. Miller authored
      Jason A. Donenfeld says:
      
      ====================
      WireGuard CI and housekeeping
      
      This is a collection of commits gathered during the last 1.5 weeks since
      merging WireGuard. If you'd prefer, I can send tree pull requests
      instead, but I figure it might be best for now to just send things as
      full patch sets to netdev.
      
      The first part of this adds in the CI test harness that we've been using
      for quite some time with success. You can type `make` and get the
      selftests running in a fresh VM immediately. This has been an
      instrumental tool in developing WireGuard, and I think it'd benefit most
      from being in-tree alongside the selftests that are already there. Once
      this lands, I plan to get build.wireguard.com building wireguard-
      linux.git and net-next.git on every single commit pushed, and do so on a
      bunch of different architectures. As this migrates into Linus' tree
      eventually and then into net.git, I'll get net.git building there too on
      every commit. Future work with this involves generalizing it to include
      more networking subsystem tests beyond just WireGuard, but one step at a
      time. In the process of porting this to the tree, the builder uncovered
      a mistake in the config menu file, which the second commit fixes.
      
      The last three commits are small housekeeping things, fixing spelling
      mistakes, replacing call_rcu with kfree_rcu, and removing an unused
      include.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f6dded1
    • Wei Yongjun's avatar
      wireguard: allowedips: use kfree_rcu() instead of call_rcu() · d89ee7d5
      Wei Yongjun authored
      The callback function of call_rcu() just calls a kfree(), so we
      can use kfree_rcu() instead of call_rcu() + callback function.
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d89ee7d5
    • YueHaibing's avatar
      wireguard: main: remove unused include <linux/version.h> · 43967b6f
      YueHaibing authored
      Remove <linux/version.h> from the includes for main.c, which is unused.
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      [Jason: reworded commit message]
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      43967b6f
    • Josh Soref's avatar
      wireguard: global: fix spelling mistakes in comments · a2ec8b57
      Josh Soref authored
      This fixes two spelling errors in source code comments.
      Signed-off-by: default avatarJosh Soref <jsoref@gmail.com>
      [Jason: rewrote commit message]
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2ec8b57
    • Jason A. Donenfeld's avatar
      wireguard: Kconfig: select parent dependency for crypto · d7c68a38
      Jason A. Donenfeld authored
      This fixes the crypto selection submenu depenencies. Otherwise, we'd
      wind up issuing warnings in which certain dependencies we also select
      couldn't be satisfied. This condition was triggered by the addition of
      the test suite autobuilder in the previous commit.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7c68a38
    • Jason A. Donenfeld's avatar
      wireguard: selftests: import harness makefile for test suite · 65d88d04
      Jason A. Donenfeld authored
      WireGuard has been using this on build.wireguard.com for the last
      several years with considerable success. It allows for very quick and
      iterative development cycles, and supports several platforms.
      
      To run the test suite on your current platform in QEMU:
      
        $ make -C tools/testing/selftests/wireguard/qemu -j$(nproc)
      
      To run it with KASAN and such turned on:
      
        $ DEBUG_KERNEL=yes make -C tools/testing/selftests/wireguard/qemu -j$(nproc)
      
      To run it emulated for another platform in QEMU:
      
        $ ARCH=arm make -C tools/testing/selftests/wireguard/qemu -j$(nproc)
      
      At the moment, we support aarch64_be, aarch64, arm, armeb, i686, m68k,
      mips64, mips64el, mips, mipsel, powerpc64le, powerpc, and x86_64.
      
      The system supports incremental rebuilding, so it should be very fast to
      change a single file and then test it out and have immediate feedback.
      
      This requires for the right toolchain and qemu to be installed prior.
      I've had success with those from musl.cc.
      
      This is tailored for WireGuard at the moment, though later projects
      might generalize it for other network testing.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      65d88d04
    • Aditya Pakki's avatar
      net: caif: replace BUG_ON with recovery code · c5dea815
      Aditya Pakki authored
      In caif_xmit, there is a crash if the ptr dev is NULL. However, by
      returning the error to the callers, the error can be handled. The
      patch fixes this issue.
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5dea815
    • Aditya Pakki's avatar
      fore200e: Fix incorrect checks of NULL pointer dereference · bbd20c93
      Aditya Pakki authored
      In fore200e_send and fore200e_close, the pointers from the arguments
      are dereferenced in the variable declaration block and then checked
      for NULL. The patch fixes these issues by avoiding NULL pointer
      dereferences.
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bbd20c93
    • David S. Miller's avatar
      Merge branch 'Simplify-IPv4-route-offload-API' · 03d51c4f
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      Simplify IPv4 route offload API
      
      Motivation
      ==========
      
      The aim of this patch set is to simplify the IPv4 route offload API by
      making the stack a bit smarter about the notifications it is generating.
      This allows driver authors to focus on programming the underlying device
      instead of having to duplicate the IPv4 route insertion logic in their
      driver, which is error-prone.
      
      This is the first patch set out of a series of four. Subsequent patch
      sets will simplify the IPv6 API, add offload/trap indication to routes
      and add tests for all the code paths (including error paths). Available
      here [1].
      
      Details
      =======
      
      Today, whenever an IPv4 route is added or deleted a notification is sent
      in the FIB notification chain and it is up to offload drivers to decide
      if the route should be programmed to the hardware or not. This is not an
      easy task as in hardware routes are keyed by {prefix, prefix length,
      table id}, whereas the kernel can store multiple such routes that only
      differ in metric / TOS / nexthop info.
      
      This series makes sure that only routes that are actually used in the
      data path are notified to offload drivers. This greatly simplifies the
      work these drivers need to do, as they are now only concerned with
      programming the hardware and do not need to replicate the IPv4 route
      insertion logic and store multiple identical routes.
      
      The route that is notified is the first FIB alias in the FIB node with
      the given {prefix, prefix length, table ID}. In case the route is
      deleted and there is another route with the same key, a replace
      notification is emitted. Otherwise, a delete notification is emitted.
      
      The above means that in the case of multiple routes with the same key,
      but different TOS, only the route with the highest TOS is notified.
      While the kernel can route a packet based on its TOS, this is not
      supported by any hardware devices I am familiar with. Moreover, this is
      not supported by IPv6 nor by BIRD/FRR from what I could see. Offload
      drivers should therefore use the presence of a non-zero TOS as an
      indication to trap packets matching the route and let the kernel route
      them instead. mlxsw has been doing it for the past two years.
      
      Testing
      =======
      
      To ensure there is no degradation in route insertion rates, I averaged
      the insertion rate of 512k routes (/24 and /32) over 50 runs. Did not
      observe any degradation.
      
      Functional tests are available here [1]. They rely on route trap
      indication, which is only added in the last patch set.
      
      In addition, I have been running syzkaller for the past week with all
      four patch sets and debug options enabled. Did not observe any problems.
      
      Patch set overview
      ==================
      
      Patches #1-#8 gradually introduce the new FIB notifications
      Patch #9 converts mlxsw to use the new notifications
      Patch #10 converts the remaining listeners and removes the old
      notifications
      
      v2:
      * Extend fib_find_alias() with another argument instead of introducing a
        new function (David Ahern)
      
      RFC: https://patchwork.ozlabs.org/cover/1170530/
      
      [1] https://github.com/idosch/linux/tree/fib-notifier
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03d51c4f
    • Ido Schimmel's avatar
      ipv4: Remove old route notifications and convert listeners · 446f7391
      Ido Schimmel authored
      Unlike mlxsw, the other listeners to the FIB notification chain do not
      require any special modifications as they never considered multiple
      identical routes.
      
      This patch removes the old route notifications and converts all the
      listeners to use the new replace / delete notifications.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      446f7391
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Start using new IPv4 route notifications · b6a1d871
      Ido Schimmel authored
      With the new notifications mlxsw does not need to handle identical
      routes itself, as this is taken care of by the core IPv4 code.
      
      Instead, mlxsw only needs to take care of inserting and removing routes
      from the device.
      
      Convert mlxsw to use the new IPv4 route notifications and simplify the
      code.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6a1d871
    • Ido Schimmel's avatar
      ipv4: Only Replay routes of interest to new listeners · 20d15652
      Ido Schimmel authored
      When a new listener is registered to the FIB notification chain it
      receives a dump of all the available routes in the system. Instead, make
      sure to only replay the IPv4 routes that are actually used in the data
      path and are of any interest to the new listener.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20d15652