1. 16 1月, 2014 30 次提交
  2. 15 1月, 2014 10 次提交
    • D
      Merge branch 'i40e-next' · e3e4e01c
      David S. Miller 提交于
      Aaron Brown says:
      
      ====================
      Intel Wired LAN Driver Updates
      
      This series contains updates to i40e from Greg Rose for VLAN filtering.
      
      Greg Rose (2):
        i40e: Warn admin to reload VF driver on port VLAN configuration.
          When an administrator sets a port VLAN filters for the virtual
          function (VF) after the VF has already set its own VLAN filters a
          conflict requiring the VF be reloaded can occur.  This patch logs a
          message indicating to the system administrator that the VF driver
          must be reloaded for the new port VLAN settings to take effect
      
        i40e: Retain MAC filters on port VLAN deletion
          On port VLAN deletion the list of MAC filters for the virtual function
          (VF) VSI were all deleted.  Let's keep them around, they come in
          handy for keeping the VF functional.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3e4e01c
    • G
      i40e: Retain MAC filters on port VLAN deletion · 8d82a7c5
      Greg Rose 提交于
      On port VLAN deletion the list of MAC filters for the virtual function (VF)
      VSI were all deleted.  Let's keep them around, they come in handy for keeping
      the VF functional.
      
      Change-Id: I335e760392f274dc8b8b40efcb708f65b49d7973
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Tested-by: NSibai Li <sibai.li@intel.com>
      Signed-off-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d82a7c5
    • G
      i40e: Warn admin to reload VF driver on port VLAN configuration · 99a4973c
      Greg Rose 提交于
      The i40e Physical Function (PF) driver will allow the
       Virtual Function (VF) driver to configure its own VLAN filters if no port
       VLAN filter has been configured.  This leads to the possibility of the
       administrator setting a port VLAN filter for the VF after the VF has already
       configured its own VLAN filters.  This leads to a conflict that can only be
       resolved by reloading the VF driver.  When the conflicting administrative
       command is detected in setting the port VLAN then log a message indicating to
       the system administrator that he must now reload the VF driver for the new
       port VLAN settings to take effect.
      
      Change-Id: I8de73b885d944a043aff32226297e4249862bcad
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Tested-by: NSibai Li <sibai.li@intel.com>
      Signed-off-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      99a4973c
    • D
      Merge branch 'vxlan_lower_dev_unregister' · e07d4ca8
      David S. Miller 提交于
      Daniel Borkmann says:
      
      ====================
      vxlan updates
      
      Did the split into two patches upon request from Cong Wang.
      
      Changelog:
      
       v1->v2:
        - Removed BUG_ON as it's not needed.
       v2->v3:
        - Removed dev->reg_state check for netns.
       v3->v4:
        - Removed list_del(), we seem to do it in some places and
          in some others not; we agreed it's not really necessary.
        - Split patch into 2 patches, notifier part and module
          unload cleanup part.
      ====================
      Reviewed-by: NCong Wang <cwang@twopensource.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e07d4ca8
    • D
      net: vxlan: properly cleanup devs on module unload · 8425783c
      Daniel Borkmann 提交于
      We should use vxlan_dellink() handler in vxlan_exit_net(), since
      i) we're not in fast-path and we should be consistent in dismantle
      just as we would remove a device through rtnl ops, and more
      importantly, ii) in case future code will kfree() memory in
      vxlan_dellink(), we would leak it right here unnoticed. Therefore,
      do not only half of the cleanup work, but make it properly.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8425783c
    • D
      net: vxlan: when lower dev unregisters remove vxlan dev as well · acaf4e70
      Daniel Borkmann 提交于
      We can create a vxlan device with an explicit underlying carrier.
      In that case, when the carrier link is being deleted from the
      system (e.g. due to module unload) we should also clean up all
      created vxlan devices on top of it since otherwise we're in an
      inconsistent state in vxlan device. In that case, the user needs
      to remove all such devices, while in case of other virtual devs
      that sit on top of physical ones, it is usually the case that
      these devices do unregister automatically as well and do not
      leave the burden on the user.
      
      This work is not necessary when vxlan device was not created with
      a real underlying device, as connections can resume in that case
      when driver is plugged again. But at least for the other cases,
      we should go ahead and do the cleanup on removal.
      
      We don't register the notifier during vxlan_newlink() here since
      I consider this event rather rare, and therefore we should not
      bloat vxlan's core structure unecessary. Also, we can simply make
      use of unregister_netdevice_many() to batch that. fdb is flushed
      upon ndo_stop().
      
      E.g. `ip -d link show vxlan13` after carrier removal before
      this patch:
      
      5: vxlan13: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default
          link/ether 1e:47:da:6d:4d:99 brd ff:ff:ff:ff:ff:ff promiscuity 0
          vxlan id 13 group 239.0.0.10 dev 2 port 32768 61000 ageing 300
                                       ^^^^^
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      acaf4e70
    • D
      Merge branch 'intel-next' · fb52cab5
      David S. Miller 提交于
      Aaron Brown says:
      
      ====================
      Intel Wired LAN Driver Updates, ixgbe: Add LER support
      
      The following patches add Live Error Recovery (LER) support to the
      ixgbe driver. This support also improves behavior in Thunderbolt
      environments. This involves checking all register reads for a
      value of all ones and when that is seen, to read the status
      register, which should never properly return all ones, to
      confirm whether the received value was correct. When this detects
      a removal, the hw_addr field is cleared to indicate the removal.
      This then blocks subsequent access to the device registers.
      
      All register access macros have been changed to static inline
      functions and all register accesses now use them.· Macro versions
      are temporarily provided.
      
      The __IXGBE_DOWN bit is no longer overloaded to also mean that
      device removal has been initiated. Now the bit can be used to
      protect ixgbe_down from multiple entry via test_and_set_bit. A
      needed smp_mb__before_clear_bit was also added.
      
      V2 Changes:
      - Use ACCESS_ONCE where needed, thanks to Ben Hutchings
      - Fix crash on module removal
      - Use boolean values for boolean returns instead of 0 and 1
      - Reword Kconfig help text
      
      V3 Changes:
      - Drop config option, per David Miller
      - Drop tail register write checks, per Alexander Duyck
      - Change writeq implementation to a static inline, thanks to Joe Perches
      
      V4 Changes:
      - Change __IXGBE_REMOVE to __IXGBE_REMOVING, per Scott Feldman's comment
      - Add #define writeq writeq, per Alexander Duyck
      - Change static inline functions to lower case, per David Miller
      - Use new lower case names in added and modified register accesses
      - Provide temporary upper case macros for register access functions
      - Change IXGBE_REMOVED from macro to static inline and change references
      - Correct IXGBE_WRITE_FLUSH to properly enclose parameter expansion
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb52cab5
    • M
      ixgbe: Additional adapter removal checks · b0483c8f
      Mark Rustad 提交于
      Additional checks are needed for a detected removal not to cause
      problems. Some involve simply avoiding a lot of stuff that can't
      do anything good, and also cases where the phony return value can
      cause problems. In addition, down the adapter when the removal is
      sensed.
      Signed-off-by: NMark Rustad <mark.d.rustad@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0483c8f
    • M
      ixgbe: Check for adapter removal on register writes · b12babd4
      Mark Rustad 提交于
      Prevent writes to an adapter that has been detected as removed
      by a previous failing read. This also fixes some include file
      ordering confusion that this patch revealed.
      Signed-off-by: NMark Rustad <mark.d.rustad@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b12babd4
    • M
      ixgbe: Check register reads for adapter removal · 2a1a091c
      Mark Rustad 提交于
      Check all register reads for adapter removal by checking the status
      register after any register read that returns 0xFFFFFFFF. Since the
      status register will never return 0xFFFFFFFF unless the adapter is
      removed, such a value from a status register read confirms the
      removal.
      Signed-off-by: NMark Rustad <mark.d.rustad@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2a1a091c