1. 17 Feb, 2016 24 commits
  2. 16 Feb, 2016 16 commits
    • Richard Alpe's avatar
      tipc: refactor node xmit and fix memory leaks · 4952cd3e
      Richard Alpe authored
      Refactor tipc_node_xmit() to fail fast and fail early. Fix several
      potential memory leaks in unexpected error paths.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Reviewed-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarRichard Alpe <richard.alpe@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4952cd3e
    • Amitoj Kaur Chawla's avatar
      dmascc: Return correct error codes · 37ace20a
      Amitoj Kaur Chawla authored
      This change has been made with the goal that kernel functions should
      return something more descriptive than -1 on failure.
      
      A variable `err` has been introduced for storing error codes.
      
      The return value of kzalloc on failure should return a -1 and not a
      -ENOMEM. This was found using Coccinelle. A simplified version of
      the semantic patch used is:
      
      //<smpl>
      @@
      expression *e;
      identifier l1;
      @@
      
      e = kzalloc(...);
      if (e == NULL) {
      ...
      goto l1;
      }
      l1:
      ...
      return -1
      + -ENOMEM
      ;
      //</smpl
      
      Furthermore, set `err` to -ENOMEM on failure of alloc_netdev(), and to
      -ENODEV on failure of register_netdev() and probe_irq_off().
      
      The single call site only checks that the return value is not 0,
      hence no change is required at the call site.
      Signed-off-by: default avatarAmitoj Kaur Chawla <amitoj1606@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      37ace20a
    • David S. Miller's avatar
      Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue · 31d035a0
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      1GbE Intel Wired LAN Driver Updates 2016-02-15
      
      This series contains updates to igb only.
      
      Shota Suzuki cleans up unnecessary flag setting for 82576 in
      igb_set_flag_queue_pairs() since the default block already sets
      IGB_FLAG_QUEUE_PAIRS to the correct value anyways, so the e1000_82576
      code block is not necessary and we can simply fall through.  Then fixes
      an issue where IGB_FLAG_QUEUE_PAIRS can now be set by using "ethtool -L"
      option but is never cleared unless the driver is reloaded, so clear the
      queue pairing if the pairing becomes unnecessary as a result of "ethtool
      -L".
      
      Mitch fixes the igbvf from giving up if it fails to get the hardware
      mailbox lock.  This can happen when the PF-VF communication channel is
      heavily loaded and causes complete communications failure between the
      PF and VF drivers, so add a counter and a delay so that the driver will
      now retry ten times before giving up on getting the mailbox lock.
      
      The remaining patches in the series are from Alex Duyck, starting with the
      cleaning up code that sets the MAC address.  Then refactors the VFTA and
      VLVF configuration, to simplify and update to similar setups in the ixgbe
      driver.  Fixed an issue were VLANs headers size was being added to the
      value programmed into the RLPML registers, yet these registers already
      take into account the size of the VLAN headers when determining the
      maximum packet length, so we can drop the code that adds the size to
      the RLPML registers.  Cleaned up the configuration of the VF port based
      VLAN configuration.  Also fixed the igb driver so that we can fully
      support SR-IOV or the recently added NTUPLE filtering while allowing
      support for VLAN promiscuous mode.  Also added the ability to use the
      bridge utility to add a FDB entry for the PF to an igb port.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31d035a0
    • David S. Miller's avatar
      Merge branch 'ethtool-channels-rxfh-conflict' · 9a14b1c2
      David S. Miller authored
      Jacob Keller says:
      
      ====================
      ethtool: correct {GS}CHANNELS and {GS}RXFH conflict
      
      This patch series fixes up ethtool_set_channels operation which
      allowed modifying the RXFH table indirectly by reducing the number of
      queues below the current max queue used by the Rx flow table. Most
      drivers incorrectly allowed this to destroy the Rx flow table and
      would then start by reinitializing it to default settings. However,
      drivers are not able to correctly handle the conflict since there was
      no way to differentiate between the default settings and the user
      requested explicit settings.
      
      To fix this, implement a new netdev private flag which we use to
      indicate whether the RXFH has been user configured. If someone has
      a better alternative of how to store this information, let me know.
      I am not sure that priv_flags is the best solution but I have not had
      any better idea.
      
      Secondly, we add a function which just calls the driver's get_rxfh
      callback to determine the current indirection table. Loop through this
      and we can determine the current highest queue that will be used by
      RSS.
      
      Now, modify ethtool_set_channels to add a check ensuring that if (a)
      we have had rxfh configured by user, (b) we can get the maximum RSS
      queue currently used, then we ensure that the newly requested Rx count
      (or combined count) is at least as high as this maximum RSS queue. The
      reasoning here is that we can always safely increase the number of
      queues. If we decrease the queues we must ensure that the decrease
      does not go lower than the highest in-use queue for the Rx flow table.
      
      Drivers may still need to be patched if they currently overwrite the
      Rx flow table during channel configuration. If the driver currently
      always resets Rx flow table when increasing number of queues it must
      be patched to only do this when netif_is_rxfh_configured returns
      false.
      
      The second patch simply adds a check to ensure that all provided
      channel counts fit within driver defined maximums.
      
      The third patch fixes fm10k to correctly reconfigure the RSS reta
      table whenever it is still unconfigured. This means that the default
      state will provide RSS to every queue. Once the user has configured
      RXFH, then we should maintain it. In addition, since the case where we
      must reconfigure the RSS table in this case should now no longer
      occur, add a dev_err message to indicate the user that we did so.
      
      I have also supplied an ethtool patch to enable setting the default Rx
      flow indirection table. Without this, current ethtool does not support
      sending an indir_size of 0, and thus does not correctly support
      configuring back to the default.
      
      Changes in v2:
      * fixed compile error
      * fixed incorrect comparison with max_rx_in_use
      * adjusted looping over dev_size
      * removed inline on function
      * dropped patch about separating combined vs asymmetric channels
      * verified behavior using fm10k driver
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9a14b1c2
    • Keller, Jacob E's avatar
      fm10k: don't reinitialize RSS flow table when RXFH configured · 1012014e
      Keller, Jacob E authored
      Also print an error message incase we do have to reconfigure as this
      should no longer happen anymore due to ethtool changes. If it somehow
      does occur, user should be made aware of it.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1012014e
    • Keller, Jacob E's avatar
      ethtool: ensure channel counts are within bounds during SCHANNELS · 8bf36862
      Keller, Jacob E authored
      Add a sanity check to ensure that all requested channel sizes are within
      bounds, which should reduce errors in driver implementation.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8bf36862
    • Keller, Jacob E's avatar
      ethtool: correctly ensure {GS}CHANNELS doesn't conflict with GS{RXFH} · d4ab4286
      Keller, Jacob E authored
      Ethernet drivers implementing both {GS}RXFH and {GS}CHANNELS ethtool ops
      incorrectly allow SCHANNELS when it would conflict with the settings
      from SRXFH. This occurs because it is not possible for drivers to
      understand whether their Rx flow indirection table has been configured
      or is in the default state. In addition, drivers currently behave in
      various ways when increasing the number of Rx channels.
      
      Some drivers will always destroy the Rx flow indirection table when this
      occurs, whether it has been set by the user or not. Other drivers will
      attempt to preserve the table even if the user has never modified it
      from the default driver settings. Neither of these situation is
      desirable because it leads to unexpected behavior or loss of user
      configuration.
      
      The correct behavior is to simply return -EINVAL when SCHANNELS would
      conflict with the current Rx flow table settings. However, it should
      only do so if the current settings were modified by the user. If we
      required that the new settings never conflict with the current (default)
      Rx flow settings, we would force users to first reduce their Rx flow
      settings and then reduce the number of Rx channels.
      
      This patch proposes a solution implemented in net/core/ethtool.c which
      ensures that all drivers behave correctly. It checks whether the RXFH
      table has been configured to non-default settings, and stores this
      information in a private netdev flag. When the number of channels is
      requested to change, it first ensures that the current Rx flow table is
      not going to assign flows to now disabled channels.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4ab4286
    • Bernhard Walle's avatar
      net: fec: Add "phy-reset-active-low" property to DT · 64f10f6e
      Bernhard Walle authored
      We need that for a custom hardware that needs the reverse reset
      sequence.
      Signed-off-by: default avatarBernhard Walle <bernhard@bwalle.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64f10f6e
    • David S. Miller's avatar
      Merge branch 'bcm7xxx-cleanups' · 12d6b917
      David S. Miller authored
      Florian Fainelli says:
      
      ====================
      net: phy: bcm7xxx: Misc cleanups
      
      These two patches are cleanups to the BCM7xxx internal PHY driver:
      
      - fix a constant name missing a X (as in BCM7XXX)
      - add a macro to reduce the amount of code duplication to add new entries
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      12d6b917
    • Florian Fainelli's avatar
      net: phy: bcm7xxx: Reduce boilerplate code for 40nm EPHY · 3125c081
      Florian Fainelli authored
      Introduce a macro which helps adding new 40NM EPHY entries and reduces the
      amount of boilerplate code.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3125c081
    • Florian Fainelli's avatar
      net: phy: bcm7xxx: Make MII_BCM7XX_64CLK_MDIO naming consistent · 3ccc3055
      Florian Fainelli authored
      The driver is BCM7xxx, we were missing an additional X in the constant naming,
      fix that to be consistent.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ccc3055
    • Alexander Duyck's avatar
      igb: Add workaround for VLAN tag stripping on 82576 · bf456abb
      Alexander Duyck authored
      There was a workaround partially implemented for the 82576 that is needed
      in order for VLAN tag stripping to function correctly.  The original code
      had side effects that would make it so the workaround was active on all
      MACs.  I have updated the code so that the workaround is enabled, but
      limited to the 82576, or activated if we exceed the available unicast
      addresses.
      
      The workaround has a side effect of mirroring all of the traffic outgoing
      from the VFs back to the PF.  As such it is not recommended to use the
      82576 in promiscuous mode as it will take a performance hit, though this is
      now consistent with the performance as seen on the out-of-tree igb driver.
      
      I also limited the scope of the UTA bits all being set to only when the
      VMOLR register is enabled.  This should limit the effects of the UTA
      register so that we don't pick up any excess traffic unless promiscuous
      mode has been enabled on the PF, whereas before the PF would have ended up
      in something equivalent to unicast promiscuous mode with VLAN filtering
      otherwise.
      Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      bf456abb
    • Alexander Duyck's avatar
      igb: Enable use of "bridge fdb add" to set unicast table entries · 268f9d33
      Alexander Duyck authored
      This change makes it so that we can use the bridge utility to add a FDB
      entry for the PF to an igb port.  By doing this we can enable the VFs to
      talk to virtual ports residing on top of the PF.
      
      In addition this should also address issues with MACVLANs trying to reside
      on top of the PF as well as they would have had similar issues when added
      to the PF with SR-IOV enabled.
      Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      268f9d33
    • Alexander Duyck's avatar
      igb: Drop unnecessary checks in transmit path · 9c2f186e
      Alexander Duyck authored
      This patch drops several checks that we dropped from ixgbe some ago.  It
      should not be possible for us to be called with either of the conditional
      statements returning true so we can just drop them from the hot-path.
      Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      9c2f186e
    • Alexander Duyck's avatar
      igb: Add support for VLAN promiscuous with SR-IOV and NTUPLE · 16903caa
      Alexander Duyck authored
      This change fixes things so that we can fully support SR-IOV or the
      recently added NTUPLE filtering while allowing support for VLAN promiscuous
      mode.  By making this change we are able to support possible scenarios such
      as SR-IOV with the PF connected to a Linux bridge hosting other VMs.
      Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      16903caa
    • Alexander Duyck's avatar
      igb: Clean-up configuration of VF port VLANs · a15d9259
      Alexander Duyck authored
      This patch is meant to clean-up the configuration of the VF port based VLAN
      configuration.  The original logic was a bit muddled and had some
      undesirable side effects such as VLANs being either completely stripped
      from the port or VLANs being left when they shouldn't be.  The idea behind
      this code is to avoid any events such as spurious spoof notifications when
      we are removing one VLAN tag and replacing it with another.
      Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      a15d9259