1. 16 Dec, 2015 9 commits
  2. 15 Dec, 2015 31 commits
    • David S. Miller's avatar
      Merge branch 'end-of-ip-csum' · 93d085d2
      David S. Miller authored
      Tom Herbert says:
      
      ====================
      net: The beginning of the end for NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM
      
      Background:
      
      This patch set starts to address one front in the battle against
      protocol ossification. Protocol ossification describes the state
      that we have arrived at in the evolution of the Internet where we are
      materially limited to only using a very narrow range of protocols
      and protocol features. For instance, only TCP and UDP is sufficiently
      supported on the Internet so that deploying alternative protocols,
      such as SCTP and DCCP, are non-starters. Similarly, IP options and IPv6
      extension headers are typically not considered feasible for wide
      deployment, so we have loss the extensibility of IP protocols.
      
      Protocol ossification is not only a problem on the Internet, but in
      the data center as well. A root cause of this seems to be narrow,
      protocol specific optimizations implemented in switches (for doing
      EMCP) and in NICs (NIC offloads). These tend to be performance
      optimization around TCP and UDP packets, and these have become
      requirements to implement performant network solutions at scale.
      
      Attempts to deal with protocol ossification in data center have yielded
      ad hoc, sub-optimal solutions. A main driver of foo-over-UDP (e.g.
      GRE/UDP, MPLS/UDP) is to leverage the existing EMCP and RSS support for
      UDP by setting the source port as an entropy value. This has seen some
      success, but the cost of additional overhead and layering limits its
      usefulness.  An even more extreme solution is STT where non-TCP packets
      are spoofed as TCP to leverage NIC offloads.
      
      This patch set endeavours to address protocol ossification caused by
      techniques used in transmit checksum offload for NICs. Future work
      will address protocol ossification in the other primary NIC offloads--
      namely receive checksum offload, LSO, LRO, and RSS.
      
      NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM:
      
      NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM exemplify the problem of protocol
      ossification. These features are relics from a simpler time in the
      Internet, before encapsulation, before GRE and  IPIP. Many hardware
      vendors only saw the need to provide checksum offload for simple UDP and
      TCP packets over IPv4 (IPv6 support is an afterthought also). In today's
      Internet and data centers, checksum offload is well established as a
      valuable feature, but we can no longer afford to be contsrained to
      use a handful of protocols and features that are supported at the
      discretion of NIC vendors. Generic and protocol agnostic methods are
      needed.
      
      The actual interface that the stack uses with drivers for checksum
      offload is CHECKSUM_PARTIAL. This is a generic and protocol agnostic
      interface. A driver for a device that supports this generic
      interface advertises NETIF_F_HW_CSUM.
      
      Goals of this patch set:
      
      We propose that drivers advertise NETIF_F_HW_CSUM instead of protocol
      specific values of NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM.  If the
      driver's device is constrained (for instance it can only offlaod simple
      IPv4 and IPv6 packets) then these constraints can be checked in the
      transmit path and skb_checksum_help would be called for packets that the
      driver is unable to offload. In order to facilitate this, we add some
      helper functions that takes a specification argument indicating the
      type of packets a device is able to offload. If a packet does not match
      the specification, the helper function calls skb_checksum_help.
      
      Benefits of this approach are:
        - Simplify the stack and clarify the interface for checksum offload
        - Encourage NIC vendors to implement the generic. protocol agnostic
          checksum offload methods in hardware
        - Encourage feature parity in NIC offloads for IPv4 and IPv6
      
      Many drivers advertise NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM and it
      probably isn't feasible to convert them all in a given time frame
      (although if we could this would be a great simplification to the
      stack). A reasonable direction may be to declare that new drivers must
      use NETIF_F_HW_CSUM as NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM are
      considered deprecated.
      
      There is a class of drivers that should now be converted to advertise
      NETIF_F_HW_CSUM, namely those that support offload of ecapsulated
      checksums. These drivers have to date been using skb->encapsulation
      to infer that checksum offload is being performed for an encapsulated
      checksum. This is strictly not correct. skb->encapsulation
      indicates that the inner headers are valid in the skbuff, whereas
      the stack indicates checksum offload arguments exclusively in csum_start
      and csum_offset. At some point we may want to set the inner headers for
      an skbuff but offload the outer transport checksum, so this needs to be
      fixed.
      
      In this patch set:
      
        - Rename some of constants involved in checksum offload to be more
          reflective of their function
        - Eliminate NETIF_F_GEN_CSUM and NETIF_F_V[46]_CSUM entirely as
          unnecessary convolutions
        - Fix conditions in tcp_sendpage and tcp_sendmsg to take IP protocol
          into account when determining if checksum offload can be done
        - Add driver helper functions for determining if a checksum can
          be offloaded to a device. If not, the helper function can call
          skb_checksum_help
        - Document the checksum offload interface between the stack and
          drivers with detail and specifics
      
      Testing:
      
      Have been testing ixgbe and mlx4. No noticeable regressions seen yet.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93d085d2
    • Tom Herbert's avatar
      net: Elaborate on checksum offload interface description · 7a6ae71b
      Tom Herbert authored
      Add specifics and details the description of the interface between
      the stack and drivers for doing checksum offload. This description
      is meant to be as specific and complete as possible.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7a6ae71b
    • Tom Herbert's avatar
      net: Add driver helper functions to determine checksum offloadability · 6ae23ad3
      Tom Herbert authored
      Add skb_csum_offload_chk driver helper function to determine if a
      device with limited checksum offload capabilities is able to offload the
      checksum for a given packet.
      
      This patch includes:
        - The skb_csum_offload_chk function. Returns true if checksum is
          offloadable, else false. Optionally, in the case that the checksum
          is not offloable, the function can call skb_checksum_help to resolve
          the checksum. skb_csum_offload_chk also returns whether the checksum
          refers to an encapsulated checksum.
        - Definition of skb_csum_offl_spec structure that caller uses to
          indicate rules about what it can offload (e.g. IPv4/v6, TCP/UDP only,
          whether encapsulated checksums can be offloaded, whether checksum with
          IPv6 extension headers can be offloaded).
        - Ancilary functions called skb_csum_offload_chk_help,
          skb_csum_off_chk_help_cmn, skb_csum_off_chk_help_cmn_v4_only.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ae23ad3
    • Tom Herbert's avatar
      tcp: Fix conditions to determine checksum offload · 9a49850d
      Tom Herbert authored
      In tcp_send_sendpage and tcp_sendmsg we check the route capabilities to
      determine if checksum offload can be performed. This check currently
      does not take the IP protocol into account for devices that advertise
      only one of NETIF_F_IPV6_CSUM or NETIF_F_IP_CSUM. This patch adds a
      function to check capabilities for checksum offload with a socket
      called sk_check_csum_caps. This function checks for specific IPv4 or
      IPv6 offload support based on the family of the socket.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9a49850d
    • Tom Herbert's avatar
      net: Eliminate NETIF_F_GEN_CSUM and NETIF_F_V[46]_CSUM · c8cd0989
      Tom Herbert authored
      These netif flags are unnecessary convolutions. It is more
      straightforward to just use NETIF_F_HW_CSUM, NETIF_F_IP_CSUM,
      and NETIF_F_IPV6_CSUM directly.
      
      This patch also:
          - Cleans up can_checksum_protocol
          - Simplifies netdev_intersect_features
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c8cd0989
    • Tom Herbert's avatar
      net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK · a188222b
      Tom Herbert authored
      The name NETIF_F_ALL_CSUM is a misnomer. This does not correspond to the
      set of features for offloading all checksums. This is a mask of the
      checksum offload related features bits. It is incorrect to set both
      NETIF_F_HW_CSUM and NETIF_F_IP_CSUM or NETIF_F_IPV6 at the same time for
      features of a device.
      
      This patch:
        - Changes instances of NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK (where
          NETIF_F_ALL_CSUM is being used as a mask).
        - Changes bonding, sfc/efx, ipvlan, macvlan, vlan, and team drivers to
          use NEITF_F_HW_CSUM in features list instead of NETIF_F_ALL_CSUM.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a188222b
    • Tom Herbert's avatar
      fcoe: Use CHECKSUM_PARTIAL to indicate CRC offload · 253aab05
      Tom Herbert authored
      When setting up CRC offload set ip_summed to CHECKSUM_PARTIAL
      instead of CHECKSUM_UNNECESSARY. This is consistent with the
      definition of CHECKSUM_PARTIAL.
      
      The only driver that seems to be advertising NETIF_F_FCOE_CRC is
      ixgbe. AFICT the driver does not look at ip_summed for FCOE and
      just assumes that CRC is being offloaded.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      253aab05
    • Tom Herbert's avatar
      sctp: Rename NETIF_F_SCTP_CSUM to NETIF_F_SCTP_CRC · 53692b1d
      Tom Herbert authored
      The SCTP checksum is really a CRC and is very different from the
      standards 1's complement checksum that serves as the checksum
      for IP protocols. This offload interface is also very different.
      Rename NETIF_F_SCTP_CSUM to NETIF_F_SCTP_CRC to highlight these
      differences. The term CSUM should be reserved in the stack to refer
      to the standard 1's complement IP checksum.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      53692b1d
    • Tom Herbert's avatar
      net: Add skb_inner_transport_offset function · 55dc5a9f
      Tom Herbert authored
      Same thing as skb_transport_offset but returns the offset of the inner
      transport header (when skb->encpasulation is set).
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      55dc5a9f
    • Kazuya Mizuguchi's avatar
      ravb: Add fixed-link support · b4bc88a8
      Kazuya Mizuguchi authored
      This patch adds support of the fixed PHY.
      This patch is based on commit 87009814 ("ucc_geth: use the new fixed
      PHY helpers").
      Signed-off-by: default avatarKazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
      Signed-off-by: default avatarYoshihiro Kaneko <ykaneko0929@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b4bc88a8
    • David S. Miller's avatar
      Merge branch 'mlxsw-bridge-vlan-offloading' · a7159a3f
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      This patchset introduces support for the offloading of 802.1D bridges
      between VLAN devices. These can either be VLAN devices configured on top
      of the physical ports or on top of LAG devices.
      
      Patches 1-2 deal with the necessary infrastructure changes needed in order
      to enable the above. The main change is that switchdev drivers can now know
      the device from which the switchdev op originated from.
      
      Patches 3-10 lay the groundwork for 802.1D bridges support in the mlxsw
      driver, with patch 4 doing most of the heavy lifting.
      
      Patch 11 finally offloads these bridges to hardware by listening to the
      notifications sent when the VLAN device joins or leaves a bridge. It is
      very similar to the already existing 802.1Q bridge we support.
      
      Patches 12-14 add minor modifications to allow one to bridge a VLAN device
      configured on top of LAG.
      ====================
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7159a3f
    • Ido Schimmel's avatar
      mlxsw: spectrum: Add support for VLAN devices on top of LAG · 272c4470
      Ido Schimmel authored
      When creating a VLAN device on top of LAG, we are basically creating a
      vPort on top of each of the port netdevs member in the LAG. Therefore,
      these vPorts should inherit both the LAG status and LAG ID from the
      underlying port netdevs.
      
      In addition, when the VLAN device joins or leaves a bridge each of the
      underlying vPorts should know about it and act accordingly. This is
      achieved by propagating the VLAN event down to the lower devices.
      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>
      272c4470
    • Ido Schimmel's avatar
      mlxsw: spectrum: Enable FDB records for VLAN devices on top of LAG · 64771e31
      Ido Schimmel authored
      When adding or removing FDB records of VLAN devices on top of LAG we
      should set the lag_vid parameter to the VLAN ID of the VLAN device. It
      is reserved otherwise.
      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>
      64771e31
    • Ido Schimmel's avatar
      mlxsw: reg: Add lag_vid field to SFD register · afd7f979
      Ido Schimmel authored
      Unicast LAG records in the Switch Filtering Database (SFD) register have
      a lag_vid field indicating the VLAN ID in case of vFIDs. This field is
      no longer reserved since we are going to add support for VLAN devices on
      top of LAG.
      
      Add the lag_vid field to be used by VLAN devies on top of LAG.
      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>
      afd7f979
    • Ido Schimmel's avatar
      mlxsw: spectrum: Add support for VLAN devices bridging · 26f0e7fb
      Ido Schimmel authored
      All the member VLAN devices in a bridge need to share the same vFID.
      
      To achieve that, expand the vFID struct to include the associated bridge
      device (or lack of) and allow one to lookup a vFID based on a bridge
      device.
      
      When joining a bridge, lookup the relevant vFID or create one if none
      exists. Next, make the VLAN device use the vFID.
      
      Leaving a bridge can either occur because a user removed the VLAN device
      from a bridge or because the VLAN device was deleted by the user. In the
      latter case the bridge's teardown sequence is invoked after the hardware
      vPort is already gone. Therefore, when unlinking the VLAN device from
      the real device, check if the associated vPort is bridged and act
      accordingly. The bridge's notification will be ignored in this case.
      
      Note that bridging a VLAN interface with an ordinary port netdev is
      currently not supported, but not forbidden. This will be addressed in a
      follow-up patchset.
      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>
      26f0e7fb
    • Ido Schimmel's avatar
      mlxsw: spectrum: Handle VLAN devices linking / unlinking · 9589a7b5
      Ido Schimmel authored
      When a VLAN interface is configured on top of a physical port we should
      associate the VLAN device with the matching vPort. Likewise, when it's
      removed, we should revert back to the underlying port netdev.
      
      While not a must, this is consistent with port netdevs and also provides
      a more accurate error printing via netdev_err() and friends.
      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>
      9589a7b5
    • Ido Schimmel's avatar
      mlxsw: spectrum: Adjust FDB notifications for VLAN devices · aac78a44
      Ido Schimmel authored
      FDB notifications contain the FID and port (or LAG ID) on which the MAC
      was learned. In the case of the 802.1Q bridge one can easily derive the
      matching VID - as FID equals VID - and generate the appropriate
      notification for the software bridge. With VLAN devices this is no
      longer the case, as these are associated with a vFID.
      
      Solve that by converting the FID to a vFID and lookup the matching VLAN
      device. From that derive the VID and whether learning (and learning
      sync) should occur.
      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>
      aac78a44
    • Ido Schimmel's avatar
      mlxsw: spectrum: Adjust switchdev ops for VLAN devices · 54a73201
      Ido Schimmel authored
      switchdev ops can now be called for VLAN devices and we need to be
      prepared for it. Until now they were only called for the port netdev.
      
      Use the newly propagated orig_dev passed as part of the switchdev
      attr/obj and determine whether the original device is a VLAN device. If
      so, act accordingly, otherwise continue as usual.
      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>
      54a73201
    • Ido Schimmel's avatar
      mlxsw: spectrum: Use FID instead of VID when accessing FDB · 9de6a80e
      Ido Schimmel authored
      In the Spectrum ASIC - unlike SwitchX-2 - FDB access is done by
      specifying FID as parameter and not VID.
      
      Change the relevant variables and parameters names to reflect that.
      
      Note that this was OK up until now, since FID was always equal to VID,
      but with the introduction of VLAN interfaces this is no longer the case.
      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>
      9de6a80e
    • Ido Schimmel's avatar
      mlxsw: spectrum: Add another flood table for vFIDs · 19ae6124
      Ido Schimmel authored
      We previously used only one flood table for packets classified to vFIDs.
      However, since we are going to add support for bridges between VLAN
      interfaces (mapped to vFIDs) we need to add one more flood table.
      
      That way we can separate the flooding domain of unknown unicast traffic
      from all the rest and support flood control (as we do with the 802.1Q
      bridge).
      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>
      19ae6124
    • Ido Schimmel's avatar
      mlxsw: spectrum: Use appropriate parameter name · c06a94ef
      Ido Schimmel authored
      The __mlxsw_sp_port_flood_set function is now used to configure flooding
      for both FIDs and vFIDs, so change the parameter name to 'idx' instead
      of 'fid'. This is also consistent with hardware documentation.
      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>
      c06a94ef
    • Ido Schimmel's avatar
      mlxsw: spectrum: Split vFID range in two · 7f71eb46
      Ido Schimmel authored
      Up until now we used a 1:1 mapping - based on VID - to map a VLAN
      interface to a vFID. However, a different scheme is needed in order to
      support bridges between VLAN interfaces, as all the member interfaces -
      which can have different VIDs - need to share the same vFID.
      
      Solve that by splitting the vFID range in two:
       1. Non-bridged VLAN interfaces
       2. Bridged VLAN interfaces
      
      When a VLAN interface is created, assign it the next available vFID in
      the first range, unless one already exists for that VID or number of
      vFIDs in the range was exceeded. When interface is removed, free the
      vFID, unless other interfaces are mapped to it.
      
      To accomplish the above:
       1. Store the VID to vFID mapping in a new struct (mlxsw_sp_vfid), which
          has a global context and holds a reference count.
       2. Create a vPort (dummy in case of bridge SELF invocation) on top of
          of the physical port and hold a reference to the associated vFID.
      
      	     vfid                    vfid
      	+-------------+	        +-------------+
      	| vfid        |         | vfid        |
      	| vid         +---> ... | vid         |
      	| nr_vports   |         | nr_vports   |
      	+------+------+         +------+------+
      				       |
      	       +-----------------------+-------+
      	       |			       |
      	     vport			     vport
      	+-------------+         	+-------------+
      	| ...	      |         	| ...	      |
      	| *vfid	      +---> ... 	| *vfid	      +---> ...
      	| ...	      |         	| ...	      |
      	+------+------+         	+------+------+
      	       |                               |
      	     port			     port
      	+-------------+         	+-------------+
      	| ...         |         	| ...         |
      	| vports_list |         	| vports_list |
      	| ...         |         	| ...         |
      	+-------------+         	+-------------+
      	     swXpY			     swXpZ
      
      Next patches in the series will add the missing infrastructure for the
      second range and transfer vPorts between the two ranges according to the
      received notifications.
      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>
      7f71eb46
    • Ido Schimmel's avatar
      mlxsw: spectrum: Allocate active VLANs only for port netdevs · bd40e9d6
      Ido Schimmel authored
      When adding support for bridges between VLAN interfaces, we'll introduce
      a new entity called a vPort, which is a represntation of the VLAN
      interface in the hardware.
      
      The main difference between a vPort and a physical port is that several
      FIDs can be bound to the latter, whereas only one (called a vFID) can be
      bound to the first.
      
      Therefore, it makes sense to use the same struct to represent the two,
      but to only allocate the 'active_vlans' bitmap in case of a physical
      port.
      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>
      bd40e9d6
    • Ido Schimmel's avatar
      switchdev: Pass original device to port netdev driver · 6ff64f6f
      Ido Schimmel authored
      switchdev drivers need to know the netdev on which the switchdev op was
      invoked. For example, the STP state of a VLAN interface configured on top
      of a port can change while being member in a bridge. In this case, the
      underlying driver should only change the STP state of that particular
      VLAN and not of all the VLANs configured on the port.
      
      However, current switchdev infrastructure only passes the port netdev down
      to the driver. Solve that by passing the original device down to the
      driver as part of the required switchdev object / attribute.
      
      This doesn't entail any change in current switchdev drivers. It simply
      enables those supporting stacked devices to know the originating device
      and act accordingly.
      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>
      6ff64f6f
    • Ido Schimmel's avatar
      switchdev: vlan: Use switchdev_port* in vlan_netdev_ops · 9d547833
      Ido Schimmel authored
      We need to be able to propagate static FDB entries and certain bridge
      port attributes (e.g. learning, flooding) down to the port netdev
      driver when bridge port is a VLAN interface.
      
      Achieve that by setting ndo_bridge* and ndo_fdb* in vlan_netdev_ops to
      the corresponding switchdev_port* functions. This is consistent with
      team and bond devices.
      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>
      9d547833
    • David S. Miller's avatar
      Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue · 335b3209
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      1GbE Intel Wired LAN Driver Updates 2015-12-14
      
      This series contains updates to e1000e and igb.
      
      Alex Duyck changes e1000_up() to void since it always returned 0, also
      by making it void, we can drop some code since we no longer have to worry
      about non-zero return values.
      
      Aaron Sierra removes GS40G specific defines and functions since the i210
      internal PHY can be accessed with the access functions shared by 82580,
      i350 and i354 devices.  Also removes the code to add the PHY address into
      the PCDL register address, since there is no real reason to do so.
      
      Joe updates the cable length function reports all four pairs true min, max
      and average cable length for i210.  Also updated ethtool to use enum-based
      labels instead of hard coded values.
      
      Benjamin Poirier cleans up code that is never reachable since MSI-X
      interrupts are not shared in e1000e.  Also removes the ICR read in the
      other interrupt handler, since the information is not needed and IMS is
      configured such that the only link status change can trigger the other
      interrupt handler.  Fixed in MSI-X mode, there is no handler for the LSC
      interrupt so there is no point in writing that to ICS now that we always
      assume other interrupts are caused by LSC.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      335b3209
    • Benjamin Poirier's avatar
      e1000e: Fix msi-x interrupt automask · 0a8047ac
      Benjamin Poirier authored
      Since the introduction of 82574 support in e1000e, the driver has worked
      on the assumption that msi-x interrupt generation is automatically
      disabled after each irq. As it turns out, this is not the case.
      Currently, rx interrupts can fire multiple times before and during napi
      processing. This can be a problem for users because frames that arrive
      in a certain window (after adapter->clean_rx() but before
      napi_complete_done() has cleared NAPI_STATE_SCHED) generate an interrupt
      which does not lead to napi_schedule(). These frames sit in the rx queue
      until another frame arrives (a tcp retransmit for example).
      
      While the EIAC and CTRL_EXT registers are properly configured for irq
      automask, the modification of IAM in e1000_configure_msix() is what
      prevents automask from working as intended.
      
      This patch removes that erroneous write and fixes interrupt rearming for
      tx interrupts. It also clears IAME from CTRL_EXT. This is not strictly
      necessary for operation of the driver but it is to avoid disruption from
      potential programs that access the registers directly, like `ethregs -c`.
      Reported-by: default avatarFrank Steiner <steiner-reg@bio.ifi.lmu.de>
      Signed-off-by: default avatarBenjamin Poirier <bpoirier@suse.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0a8047ac
    • Benjamin Poirier's avatar
      e1000e: Do not write lsc to ics in msi-x mode · a61cfe4f
      Benjamin Poirier authored
      In msi-x mode, there is no handler for the lsc interrupt so there is no
      point in writing that to ics now that we always assume Other interrupts
      are caused by lsc.
      Reviewed-by: default avatarJasna Hodzic <jhodzic@ucdavis.edu>
      Signed-off-by: default avatarBenjamin Poirier <bpoirier@suse.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      a61cfe4f
    • Benjamin Poirier's avatar
      e1000e: Do not read ICR in Other interrupt · 16ecba59
      Benjamin Poirier authored
      Removes the ICR read in the other interrupt handler, uses EIAC to
      autoclear the Other bit from ICR and IMS. This allows us to avoid
      interference with Rx and Tx interrupts in the Other interrupt handler.
      
      The information read from ICR is not needed. IMS is configured such that
      the only interrupt cause that can trigger the Other interrupt is Link
      Status Change.
      Signed-off-by: default avatarBenjamin Poirier <bpoirier@suse.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      16ecba59
    • Benjamin Poirier's avatar
      e1000e: Remove unreachable code · 4d432f67
      Benjamin Poirier authored
      msi-x interrupts are not shared so there's no need to check if the
      interrupt was really from this adapter.
      Signed-off-by: default avatarBenjamin Poirier <bpoirier@suse.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4d432f67
    • Gregory CLEMENT's avatar
      net/macb: add support for resetting PHY using GPIO · 5833e052
      Gregory CLEMENT authored
      With device tree it is no more possible to reset the PHY at board
      level. Furthermore, doing in the driver allow to power down the PHY when
      the network interface is no more used.
      
      This reset can't be done at the PHY driver level. The PHY must be able to
      answer the to the mii bus scan to let the kernel creating a PHY device.
      
      The patch introduces a new optional property "phy-reset-gpios" inspired
      from the one use for the FEC.
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5833e052