1. 27 Feb, 2020 6 commits
  2. 26 Feb, 2020 1 commit
  3. 25 Feb, 2020 11 commits
  4. 24 Feb, 2020 22 commits
    • David S. Miller's avatar
      Merge tag 'mac80211-next-for-net-next-2020-02-24' of... · 3b3e808c
      David S. Miller authored
      Merge tag 'mac80211-next-for-net-next-2020-02-24' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
      
      Johannes Berg says:
      
      ====================
      A new set of changes:
       * lots of small documentation fixes, from Jérôme Pouiller
       * beacon protection (BIGTK) support from Jouni Malinen
       * some initial code for TID configuration, from Tamizh chelvam
       * I reverted some new API before it's actually used, because
         it's wrong to mix controlled port and preauth
       * a few other cleanups/fixes
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b3e808c
    • Colin Ian King's avatar
      net: qrtr: fix spelling mistake "serivce" -> "service" · 13ef6ae8
      Colin Ian King authored
      There is a spelling mistake in a pr_err message. Fix it.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13ef6ae8
    • Ahmad Fatoum's avatar
      net: ethernet: stmmac: don't warn about missing optional wakeup IRQ · d87ab44a
      Ahmad Fatoum authored
      The "stm32_pwr_wakeup" is optional per the binding and the driver
      handles its absence gracefully. Request it with
      platform_get_irq_byname_optional, so its absence doesn't needlessly
      clutter the log.
      Signed-off-by: default avatarAhmad Fatoum <a.fatoum@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d87ab44a
    • Ahmad Fatoum's avatar
      net: ethernet: stmmac: demote warnings about missing optional clocks · 07cc79ef
      Ahmad Fatoum authored
      The specification of a "eth-ck" and a "ptp_ref" clock is optional per
      the binding and the driver handles them gracefully.
      Demote the output to an info message accordingly.
      Signed-off-by: default avatarAhmad Fatoum <a.fatoum@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07cc79ef
    • David S. Miller's avatar
      Merge branch 'Add-ACPI-bindings-to-the-genet' · e2763bc4
      David S. Miller authored
      Jeremy Linton says:
      
      ====================
      Add ACPI bindings to the genet
      
      This patch series allows the BCM GENET, as used on the RPi4,
      to attach when booted in an ACPI environment. The DSDT entry to
      trigger this is seen below. Of note, the first patch adds a
      small extension to the mdio layer which allows drivers to find
      the mii_bus without firmware assistance. The fifth patch in
      the set retrieves the MAC address from the umac registers
      rather than carrying it directly in the DSDT. This of course
      requires the firmware to pre-program it, so we continue to fall
      back on a random one if it appears to be garbage.
      
      v1 -> v2:
           fail on missing phy-mode property
           replace phy-mode internal property read string with
           	     device_get_phy_mode() equivalent
           rework mac address detection logic so that it merges
           	    the acpi/DT case into device_get_mac_address()
      	    allowing _DSD mac address properties.
           some commit messages justifying why phy_find_first()
           	    isn't the worst choice for this driver.
      
      +    Device (ETH0)
      +    {
      +      Name (_HID, "BCM6E4E")
      +      Name (_UID, 0)
      +      Name (_CCA, 0x0)
      +      Method (_STA)
      +      {
      +        Return (0xf)
      +      }
      +      Method (_CRS, 0x0, Serialized)
      +      {
      +        Name (RBUF, ResourceTemplate ()
      +        {
      +          Memory32Fixed (ReadWrite, 0xFd580000, 0x10000, )
      +          Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 0xBD }
      +          Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 0xBE }
      +        })
      +        Return (RBUF)
      +      }
      +      Name (_DSD, Package () {
      +        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
      +          Package () {
      +          Package () { "phy-mode", "rgmii-rxid" },
      +        }
      +      })
      +    }
      ====================
      Tested-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e2763bc4
    • Jeremy Linton's avatar
      net: bcmgenet: reduce severity of missing clock warnings · ae200c26
      Jeremy Linton authored
      If one types "failed to get enet clock" or similar into google
      there are ~370k hits. The vast majority are people debugging
      problems unrelated to this adapter, or bragging about their
      rpi's. Further, the DT clock bindings here are optional.
      
      Given that its not a fatal situation with common DT based
      systems, lets reduce the severity so people aren't seeing failure
      messages in everyday operation.
      Signed-off-by: default avatarJeremy Linton <jeremy.linton@arm.com>
      Reviewed-by: default avatarNicolas Saenz Julienne <nsaenzjulienne@suse.de>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae200c26
    • Jeremy Linton's avatar
      net: bcmgenet: Fetch MAC address from the adapter · 26bd9cc6
      Jeremy Linton authored
      ARM/ACPI machines should utilize self describing hardware
      when possible. The MAC address on the BCMGENET can be
      read from the adapter if a full featured firmware has already
      programmed it. Lets try using the address already programmed,
      if it appears to be valid.
      
      It should be noted that while we move the macaddr logic below
      the clock and power logic in the driver, none of that code will
      ever be active in an ACPI environment as the device will be
      attached to the acpi power domain, and brought to full power
      with all clocks enabled immediately before the device probe
      routine is called.
      
      One side effect of the above tweak is that while its now
      possible to read the MAC address via _DSD properties, it should
      be avoided.
      Signed-off-by: default avatarJeremy Linton <jeremy.linton@arm.com>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26bd9cc6
    • Jeremy Linton's avatar
      net: bcmgenet: Initial bcmgenet ACPI support · 99c6b06a
      Jeremy Linton authored
      The rpi4 is capable of booting in ACPI mode with the latest
      edk2-platform commits. As such it would be helpful if the genet
      platform device were usable.
      
      To achieve this we add a new MODULE_DEVICE_TABLE, and convert
      a few dt specific methods to their generic device_ calls. Until
      the next patch, ACPI based machines will fallback on random
      mac addresses.
      Signed-off-by: default avatarJeremy Linton <jeremy.linton@arm.com>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99c6b06a
    • Jeremy Linton's avatar
      net: bcmgenet: enable automatic phy discovery · 6ef31c8b
      Jeremy Linton authored
      The unimac mdio driver falls back to scanning the
      entire bus if its given an appropriate mask. In ACPI
      mode we expect that the system is well behaved and
      conforms to recent versions of the specification.
      
      We then utilize phy_find_first(), and
      phy_connect_direct() to find and attach to the
      discovered phy during net_device open. While its
      apparently possible to build a genet based device
      with multiple phys on a single mdio bus, this works
      for current machines. Further, this driver makes
      a number of assumptions about the platform device,
      mac, mdio and phy all being 1:1. Lastly, It also
      avoids having to create references across the ACPI
      namespace hierarchy.
      Signed-off-by: default avatarJeremy Linton <jeremy.linton@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ef31c8b
    • Jeremy Linton's avatar
      net: bcmgenet: refactor phy mode configuration · 480ded26
      Jeremy Linton authored
      The DT phy mode is similar to what we want for ACPI
      lets factor it out of the of path, and change the
      of_ call to device_.
      Signed-off-by: default avatarJeremy Linton <jeremy.linton@arm.com>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      480ded26
    • Jeremy Linton's avatar
      mdio_bus: Add generic mdio_find_bus() · ce69e216
      Jeremy Linton authored
      It appears most ethernet drivers follow one of two main strategies
      for mdio bus/phy management. A monolithic model where the net driver
      itself creates, probes and uses the phy, and one where an external
      mdio/phy driver instantiates the mdio bus/phy and the net driver
      only attaches to a known phy. Usually in this latter model the phys
      are discovered via DT relationships or simply phy name/address
      hardcoding.
      
      This is a shame because modern well behaved mdio buses are self
      describing and can be probed. The mdio layer itself is fully capable
      of this, yet there isn't a clean way for a standalone net driver
      to attach and enumerate the discovered devices. This is because
      outside of of_mdio_find_bus() there isn't a straightforward way
      to acquire the mii_bus pointer.
      
      So, lets add a mdio_find_bus which can return the mii_bus based
      only on its name.
      Signed-off-by: default avatarJeremy Linton <jeremy.linton@arm.com>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce69e216
    • Gustavo A. R. Silva's avatar
      freescale: Replace zero-length array with flexible-array member · cc5b48b5
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cc5b48b5
    • Gustavo A. R. Silva's avatar
      intel: Replace zero-length array with flexible-array member · 040efdb1
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      040efdb1
    • Gustavo A. R. Silva's avatar
      netronome: Replace zero-length array with flexible-array member · 3f6e9633
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f6e9633
    • Gustavo A. R. Silva's avatar
      toshiba: Replace zero-length array with flexible-array member · f49b2759
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f49b2759
    • Gustavo A. R. Silva's avatar
      chelsio: Replace zero-length array with flexible-array member · 65dc2f1a
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      65dc2f1a
    • David S. Miller's avatar
      Merge branch 'Remainder-for-DT-bindings-for-Felix-DSA-switch-on-LS1028A' · 59bc954c
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Remainder for "DT bindings for Felix DSA switch on LS1028A"
      
      This series is the remainder of patchset [0] which has been merged
      through Shawn Guo's devicetree tree.
      
      It contains changes to the PHY mode validation in the Felix driver
      ("gmii" to "internal") and the documentation for the DT bindings.
      
      [0]: https://patchwork.ozlabs.org/cover/1242716/
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      59bc954c
    • Vladimir Oltean's avatar
      dt-bindings: net: dsa: ocelot: document the vsc9959 core · 37b558f6
      Vladimir Oltean authored
      This patch adds the required documentation for the embedded L2 switch
      inside the NXP LS1028A chip.
      
      I've submitted it in the legacy format instead of yaml schema, because
      DSA itself has not yet been converted to yaml, and this driver defines
      no custom bindings.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      37b558f6
    • Vladimir Oltean's avatar
      net: dsa: felix: Use PHY_INTERFACE_MODE_INTERNAL instead of GMII · 28a134f5
      Vladimir Oltean authored
      phy-mode = "gmii" is confusing because it may mean that the port
      supports the 8-bit-wide parallel data interface pinout, which it
      doesn't.
      
      It may also be confusing because one of the "gmii" internal ports is
      actually overclocked to run at 2.5Gbps (even though, yes, as far as the
      switch MAC is concerned, it still thinks it's gigabit).
      
      So use the phy-mode = "internal" property to describe the internal ports
      inside the NXP LS1028A chip (the ones facing the ENETC). The change
      should be fine, because the device tree bindings document is yet to be
      introduced, and there are no stable DT blobs in use.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28a134f5
    • David S. Miller's avatar
      bareudp: Fix uninitialized variable warnings. · c102b6fd
      David S. Miller authored
      drivers/net/bareudp.c: In function 'bareudp_xmit_skb':
      drivers/net/bareudp.c:346:9: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized]
        346 |  return err;
            |         ^~~
      drivers/net/bareudp.c: In function 'bareudp6_xmit_skb':
      drivers/net/bareudp.c:407:9: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized]
        407 |  return err;
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c102b6fd
    • David S. Miller's avatar
      Merge branch 'Bare-UDP-L3-Encapsulation-Module' · 8bf2464c
      David S. Miller authored
      Martin Varghese says:
      
      ====================
      Bare UDP L3 Encapsulation Module
      
      There are various L3 encapsulation standards using UDP being discussed to
      leverage the UDP based load balancing capability of different networks.
      MPLSoUDP (__ https://tools.ietf.org/html/rfc7510) is one among them.
      
      The Bareudp tunnel module provides a generic L3 encapsulation tunnelling
      support for tunnelling different L3 protocols like MPLS, IP, NSH etc. inside
      a UDP tunnel.
      
      Special Handling
      ----------------
      The bareudp device supports special handling for MPLS & IP as they can have
      multiple ethertypes.
      MPLS procotcol can have ethertypes ETH_P_MPLS_UC  (unicast) & ETH_P_MPLS_MC (multicast).
      IP protocol can have ethertypes ETH_P_IP (v4) & ETH_P_IPV6 (v6).
      This special handling can be enabled only for ethertypes ETH_P_IP & ETH_P_MPLS_UC
      with a flag called multiproto mode.
      
      Usage
      ------
      
      1) Device creation & deletion
      
          a) ip link add dev bareudp0 type bareudp dstport 6635 ethertype 0x8847.
      
             This creates a bareudp tunnel device which tunnels L3 traffic with ethertype
             0x8847 (MPLS traffic). The destination port of the UDP header will be set to
             6635.The device will listen on UDP port 6635 to receive traffic.
      
          b) ip link delete bareudp0
      
      2) Device creation with multiple proto mode enabled
      
      There are two ways to create a bareudp device for MPLS & IP with multiproto mode
      enabled.
      
          a) ip link add dev  bareudp0 type bareudp dstport 6635 ethertype 0x8847 multiproto
      
          b) ip link add dev  bareudp0 type bareudp dstport 6635 ethertype mpls
      
      3) Device Usage
      
      The bareudp device could be used along with OVS or flower filter in TC.
      The OVS or TC flower layer must set the tunnel information in SKB dst field before
      sending packet buffer to the bareudp device for transmission. On reception the
      bareudp device extracts and stores the tunnel information in SKB dst field before
      passing the packet buffer to the network stack.
      
      Why not FOU ?
      ------------
      FOU by design does l4 encapsulation.It maps udp port to ipproto (IP protocol number for l4 protocol).
      Bareudp acheives a generic l3 encapsulation.It maps udp port to l3 ethertype.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8bf2464c
    • Martin Varghese's avatar
      net: Special handling for IP & MPLS. · 4b5f6723
      Martin Varghese authored
      Special handling is needed in bareudp module for IP & MPLS as they
      support more than one ethertypes.
      
      MPLS has 2 ethertypes. 0x8847 for MPLS unicast and 0x8848 for MPLS multicast.
      While decapsulating MPLS packet from UDP packet the tunnel destination IP
      address is checked to determine the ethertype. The ethertype of the packet
      will be set to 0x8848 if the  tunnel destination IP address is a multicast
      IP address. The ethertype of the packet will be set to 0x8847 if the
      tunnel destination IP address is a unicast IP address.
      
      IP has 2 ethertypes.0x0800 for IPV4 and 0x86dd for IPv6. The version
      field of the IP header tunnelled will be checked to determine the ethertype.
      
      This special handling to tunnel additional ethertypes will be disabled
      by default and can be enabled using a flag called multiproto. This flag can
      be used only with ethertypes 0x8847 and 0x0800.
      Signed-off-by: default avatarMartin Varghese <martin.varghese@nokia.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b5f6723