1. 29 Aug, 2016 11 commits
    • Arnd Bergmann's avatar
      net/xgene: fix error handling during reset · f9dc7074
      Arnd Bergmann authored
      The newly added reset logic uses helper functions for the MMIO that
      may fail. However, when the read operation fails, we end up writing
      back uninitialized data to the register, as gcc warns:
      
      drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c: In function 'xgene_enet_link_state':
      drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c:213:2: error: 'data' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c:209:6: note: 'data' was declared here
        u32 data;
      
      We already print a warning to the console log if that happens,
      the best alternative that I can see is skip the rest of the reset
      sequence if the register value cannot be read: Most likely the
      write would fail as well, and if it succeeded, worse things could
      happen.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 3eb7cb9d ("drivers: net: xgene: XFI PCS reset when link is down")
      Cc: Fushen Chen <fchen@apm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9dc7074
    • Vidya Sagar Ravipati's avatar
      net: ethtool: add support for 1000BaseX and missing 10G link modes · 5711a982
      Vidya Sagar Ravipati authored
      This patch enhances ethtool link mode bitmap to include
      missing interface modes for 1G/10G speeds
      
      Changes:
      1000baseX is the mode introduced to cover all 1G Fiber cases.
      All modes under 1000BaseX i.e. 1000BASE-SX, 1000BASE-LX, 1000BASE-LX10
      and 1000BASE-BX10 are not explicitly defined at this moment.
      10G CR,SR,LR and ER link modes are included for 10G speed..
      
      Issue:
      ethtool on  1G/10G SFP port reports Base-T
      as this port supports 1000baseX,10G CR, SR and LR modes.
      
      root@tor-02$ ethtool swp1
      Settings for swp1:
              Supported ports: [ FIBRE ]
              Supported link modes:   1000baseT/Full
                                      10000baseT/Full
              Supported pause frame use: Symmetric Receive-only
              Supports auto-negotiation: Yes
              Advertised link modes:  1000baseT/Full
              Advertised pause frame use: No
              Advertised auto-negotiation: No
              Speed: 10000Mb/s
              Duplex: Full
              Port: FIBRE
              PHYAD: 0
              Transceiver: external
              Auto-negotiation: off
              Current message level: 0x00000000 (0)
      
              Link detected: yes
      
      After fix:
      root@tor-02$ ethtool swp1
      Settings for swp1:
              Supported ports: [ FIBRE ]
              Supported link modes:   1000baseX/Full
                                      10000baseCR/Full
                                      10000baseSR/Full
                                      10000baseLR/Full
                                      10000baseER/Full
              Supported pause frame use: Symmetric Receive-only
              Supports auto-negotiation: Yes
              Advertised link modes:  1000baseT/Full
              Advertised pause frame use: No
              Advertised auto-negotiation: No
              Speed: 10000Mb/s
              Duplex: Full
              Port: FIBRE
              PHYAD: 0
              Transceiver: external
              Auto-negotiation: off
              Current message level: 0x00000000 (0)
              Link detected: yes
      Signed-off-by: default avatarVidya Sagar Ravipati <vidya@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5711a982
    • James Morse's avatar
      amd-xgbe: Reset running devices after resume from hibernate · a039b638
      James Morse authored
      After resume from hibernate on arm64, any amd-xgbe devices that were
      running when we hibernated are reported as down, even when it is not.
      
      Re-plugging the cables does not cause the interface to come back, the
      link must be marked as down then up via 'ip set link' using the serial
      console.
      
      This happens because the device has been power-cycled and possibly
      re-initialised by firmware, whereas the driver's memory structures have
      been restored from the hibernate image and the two do not agree.
      
      Schedule a restart of the device after powerup in case the world changed
      while we were asleep.
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a039b638
    • Eric Dumazet's avatar
      tcp: add tcp_add_backlog() · c9c33212
      Eric Dumazet authored
      When TCP operates in lossy environments (between 1 and 10 % packet
      losses), many SACK blocks can be exchanged, and I noticed we could
      drop them on busy senders, if these SACK blocks have to be queued
      into the socket backlog.
      
      While the main cause is the poor performance of RACK/SACK processing,
      we can try to avoid these drops of valuable information that can lead to
      spurious timeouts and retransmits.
      
      Cause of the drops is the skb->truesize overestimation caused by :
      
      - drivers allocating ~2048 (or more) bytes as a fragment to hold an
        Ethernet frame.
      
      - various pskb_may_pull() calls bringing the headers into skb->head
        might have pulled all the frame content, but skb->truesize could
        not be lowered, as the stack has no idea of each fragment truesize.
      
      The backlog drops are also more visible on bidirectional flows, since
      their sk_rmem_alloc can be quite big.
      
      Let's add some room for the backlog, as only the socket owner
      can selectively take action to lower memory needs, like collapsing
      receive queues or partial ofo pruning.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c9c33212
    • Colin Ian King's avatar
      cxgb4/cxgb4vf: fix spelling mistake "provissioned" -> "provisioned" · 1a8ff8f5
      Colin Ian King authored
      Trivial fix to spelling mistake in dev_warn message.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a8ff8f5
    • Colin Ian King's avatar
      net: ucc_geth: fix spelling mistake "propperty" -> "property" · b9780a81
      Colin Ian King authored
      Trivial fix to spelling mistake in dev_warn message.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9780a81
    • Colin Ian King's avatar
      wan/fsl_ucc_hdlc: fix spelling mistake "prameter" -> "parameter" · 24a24d07
      Colin Ian King authored
      Trivial fix to spelling mistake in dev_err message.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24a24d07
    • David S. Miller's avatar
      Merge branch 'strp-generalization' · c6f04e93
      David S. Miller authored
      Tom Herbert says:
      
      ====================
      strp: Generalize stream parser to work with other socket types
      
      Add a read_sock protocol operation function that allows something like
      tcp_read_sock to be called for other protocol types.
      
      Specific changes in this patch set:
        - Add read_sock function to proto_ops. This has the same signature as
          tcp_read_sock. sk_read_actor_t is also defined in net.h.
        - Set peek_len and read_sock proto_op functions for TCPv4 and TCPv6
          stream ops.
        - Remove references to tcp in strparser.
        - Call peek_len and read_sock operations from strparser instead of
          calling TCP specific functions.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6f04e93
    • Tom Herbert's avatar
      kcm: Remove TCP specific references from kcm and strparser · 96a59083
      Tom Herbert authored
      kcm and strparser need to work with any type of stream socket not just
      TCP. Eliminate references to TCP and call generic proto_ops functions of
      read_sock and peek_len. Also in strp_init check if the socket support
      the proto_ops read_sock and peek_len.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96a59083
    • Tom Herbert's avatar
      tcp: Set read_sock and peek_len proto_ops · 32035585
      Tom Herbert authored
      In inet_stream_ops we set read_sock to tcp_read_sock and peek_len to
      tcp_peek_len (which is just a stub function that calls tcp_inq).
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32035585
    • Tom Herbert's avatar
      net: Add read_sock proto_op · 0294b625
      Tom Herbert authored
      Add new function in proto_ops structure. This includes moving the
      typedef got sk_read_actor into net.h and removing the definition from
      tcp.h.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0294b625
  2. 27 Aug, 2016 19 commits
  3. 26 Aug, 2016 10 commits
    • David S. Miller's avatar
      Merge branch 'bcm_sf2-utilize-b53_common' · a29ca894
      David S. Miller authored
      Florian Fainelli says:
      
      ====================
      net: dsa: Make bcm_sf2 utilize b53_common
      
      This patch series makes the bcm_sf2 driver utilize a large number of the core
      functions offered by the b53_common driver since the SWITCH_CORE registers are
      mostly register compatible with the switches driven by b53_common.
      
      In order to accomplish that, we just override the dsa_driver_ops callbacks that
      we need to. There are still integration specific logic from the bcm_sf2 that we
      cannot absorb into b53_common because it is just not there, mostly in the area
      of link management and power management, but most of the features are within
      b53_common now: VLAN, FDB, bridge
      
      Along the process, we also improve support for the BCM58xx SoCs, since those
      also have the same version of the switching IP that 7445 has (for which bcm_sf2
      was developed).
      
      Changes in v3:
      
      - rebase against 145dd5f9 ("net: flush the
        softnet backlog in process context")
      
      Changes in v2:
      
      - rebased against "net: dsa: rename switch operations structure"
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a29ca894
    • Florian Fainelli's avatar
      net: dsa: bcm_sf2: Remove duplicate code · de0b9d3b
      Florian Fainelli authored
      Now that we are using b53_common for most VLAN, FDB and bridge
      operations, delete all the redundant code that we had in bcm_sf2.c to
      keep only the integration specific logic that we have to deal with:
      power management, link management and the external interfaces (RGMII,
      MDIO).
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de0b9d3b
    • Florian Fainelli's avatar
      net: dsa: bcm_sf2: Utilize core B53 driver when possible · f458995b
      Florian Fainelli authored
      The Broadcom Starfighter2 is almost entirely register compatible with
      B53, yet for historical reasons came up first in the tree and is now
      being updated to utilize b53_common.c to the fullest extent possible. A
      few things need to be adjusted to allow that:
      
      - the switch "core" registers currently operate on a 32-bit address,
        whereas b53 passes a page + reg pair to offset from, so we need to
        convert that, thankfully there is a generic formula to do that
      
      - the link managemenent is not self contained with the B53/CORE register
        set, but instead is in the SWITCH_REG block which is part of the
        integration glue logic, so we keep that entirely custom here because
        this really is part of the existing bcm_sf2 implementation
      
      - there are additional power management constraints on the port's
        memories that make us keep the port_enable/disable callbacks custom
        for now, also, we support tagging whereas b53_common does not support
        that yet
      
      All the VLAN and bridge code is entirely identical though so, avoid
      duplicating it. Other things will be migrated in the future like EEE and
      possibly Wake-on-LAN.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f458995b
    • Florian Fainelli's avatar
      net: dsa: b53: Add JOIN_ALL_VLAN support · 48aea33a
      Florian Fainelli authored
      In order to migrate the bcm_sf2 driver over to the b53 driver for most
      VLAN/FDB/bridge operations, we need to add support for the "join all
      VLANs" register and behavior which allows us to make a given port join
      all VLANs and avoid setting specific VLAN entries when it is leaving the
      bridge.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48aea33a
    • Florian Fainelli's avatar
      net: dsa: b53: Define SF2 MIB layout · bde5d132
      Florian Fainelli authored
      The 58xx and 7445 chips use the Starfighter2 code, define its MIB layout
      and introduce a helper function: is58xx() which checks for both of these
      IDs for now.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bde5d132
    • Florian Fainelli's avatar
      net: dsa: b53: Prepare to support 7445 switch · 130401d9
      Florian Fainelli authored
      Allocate a device entry for the Broadcom BCM7445 integrated switch
      currently backed by bcm_sf2.c. Since this is the latest generation, it
      has 4 ARL entries, 4K VLANs and uses Port 8 for the CPU/IMP port.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      130401d9
    • Florian Fainelli's avatar
      net: dsa: b53: Initialize ds->ops in b53_switch_alloc · 485ebd61
      Florian Fainelli authored
      In order to allow drivers to override specific dsa_switch_driver
      callbacks, initialize ds->ops to b53_switch_ops earlier, which avoids
      having to expose this structure to glue drivers.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      485ebd61
    • David S. Miller's avatar
      Merge branch 'mlxsw-fw-mark-offload' · ed35ca99
      David S. Miller authored
      Jiri Pirko says:
      
      ====================
      mlxsw: Introduce support for offload forward mark
      
      Ido says:
      This patchset enables the forwarding of certain control packets by the
      device instead of relying on the CPU to do the forwarding.
      
      The first two patches simplify the current switchdev offload forward
      infrastructure and make it usable for stacked devices. This is done by
      moving the packet and port marking to the bridge driver instead of the
      switch driver.
      
      Patches 3-5 add the mlxsw specific bits to support the forward mark.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ed35ca99
    • Ido Schimmel's avatar
      mlxsw: spectrum: Mirror certain packets to CPU · 1c6c6d22
      Ido Schimmel authored
      Instead of trapping certain packets to the CPU and then relying on it to
      flood them we can instead make the device mirror them.
      
      The following packet types are mirrored:
      
      * DHCP: Broadcast packets that should be flooded by the device, but also
      trapped in case CPU is running the DHCP server.
      
      * IGMP query: Multicast packets that need to be forwarded to other
      bridge ports, but also trapped so that receiving netdev will be marked
      as a router port by the bridge driver.
      
      * ARP request: Broadcast packets that should be forwarded to other
      bridge ports, but also trapped in case requested IP is of the local
      machine.
      
      * ARP response: Unicast packets that should be forwarded by the bridge
      but also trapped in case response is directed at us.
      
      Set the trap action of such packets to mirror and mark them using
      'offload_fwd_mark' to prevent the bridge driver from forwarding them
      itself.
      
      Note that OSPF packets are also marked despite their action being trap.
      The reason for this is that the device traps such packets in the
      pipeline after they were already flooded.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c6c6d22
    • Ido Schimmel's avatar
      mlxsw: spectrum: Allow different traps to have different actions · 63a81141
      Ido Schimmel authored
      Up until now we only trapped packets to CPU, but we are going to allow
      some packets to be mirrored (trap & forward) to CPU.
      
      Extend the Rx listener with 'action' member.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63a81141