1. 04 6月, 2013 2 次提交
    • J
      cfg80211: separate internal SME implementation · ceca7b71
      Johannes Berg 提交于
      The current internal SME implementation in cfg80211 is
      very mixed up with the MLME handling, which has been
      causing issues for a long time. There are three things
      that the implementation has to provide:
       * a basic SME implementation for nl80211's connect()
         call (for drivers implementing auth/assoc, which is
         really just mac80211) and wireless extensions
       * MLME events for the userspace SME
       * SME events (connected, disconnected etc.) for all
         different SME implementation possibilities (driver,
         cfg80211 and userspace)
      
      To achieve these goals it isn't necessary to track the
      software SME's connection status outside of it's state
      (which is the part that caused many issues.) Instead,
      track it only in the SME data (wdev->conn) and in the
      general case only track whether the wdev is connected
      or not (via wdev->current_bss.)
      
      Also separate the internal implementation to not have
      callbacks from the SME events, but rather call it from
      the API functions that the driver (or rather mac80211)
      calls. This separates the code better.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ceca7b71
    • J
      cfg80211/mac80211: clean up cfg80211 SME APIs · 6ff57cf8
      Johannes Berg 提交于
      Do some cleanups in the cfg80211 SME APIs, which are
      only used by mac80211.
      
      Most of these functions get a frame passed, and there
      isn't really any reason to export multiple functions
      as cfg80211 can check the frame type instead, do that.
      
      Additionally, the API functions have confusing names
      like cfg80211_send_...() which was meant to indicate
      that it sends an event to userspace, but gets a bit
      confusing when there's both TX and RX and they're not
      all clearly labeled.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6ff57cf8
  2. 25 5月, 2013 3 次提交
    • J
      cfg80211: remove some locked wrappers from mlme API · 91bf9b26
      Johannes Berg 提交于
      By making all the API functions require wdev locking we
      can clean up the API a bit, getting rid of the locking
      version of each function. This also decreases the size
      of cfg80211 by a small amount.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      91bf9b26
    • J
      cfg80211/mac80211: use cfg80211 wdev mutex in mac80211 · 8d61ffa5
      Johannes Berg 提交于
      Using separate locks in cfg80211 and mac80211 has always
      caused issues, for example having to unlock in places in
      mac80211 to call cfg80211, which even needed a framework
      to make cfg80211 calls after some functions returned etc.
      
      Additionally, I suspect some issues people have reported
      with the cfg80211 state getting confused could be due to
      such issues, when cfg80211 is asking mac80211 to change
      state but mac80211 is in the process of telling cfg80211
      that the state changed (in another way.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8d61ffa5
    • J
      cfg80211: vastly simplify locking · 5fe231e8
      Johannes Berg 提交于
      Virtually all code paths in cfg80211 already (need to) hold
      the RTNL. As such, there's little point in having another
      four mutexes for various parts of the code, they just cause
      lock ordering issues (and much of the time, the RTNL and a
      few of the others need thus be held.)
      
      Simplify all this by getting rid of the extra four mutexes
      and just use the RTNL throughout. Only a few code changes
      were needed to do this and we can get rid of a work struct
      for bonus points.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5fe231e8
  3. 17 5月, 2013 1 次提交
  4. 22 4月, 2013 1 次提交
  5. 06 3月, 2013 3 次提交
  6. 15 2月, 2013 1 次提交
  7. 12 2月, 2013 1 次提交
  8. 29 1月, 2013 1 次提交
  9. 03 1月, 2013 1 次提交
  10. 26 11月, 2012 2 次提交
    • J
      cfg80211: pass a channel definition struct · 683b6d3b
      Johannes Berg 提交于
      Instead of passing a channel pointer and channel type
      to all functions and driver methods, pass a new channel
      definition struct. Right now, this struct contains just
      the control channel and channel type, but for VHT this
      will change.
      
      Also, add a small inline cfg80211_get_chandef_type() so
      that drivers don't need to use the _type field of the
      new structure all the time, which will change.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      683b6d3b
    • J
      cfg80211: remove remain-on-channel channel type · 42d97a59
      Johannes Berg 提交于
      As mwifiex (and mac80211 in the software case) are the
      only drivers actually implementing remain-on-channel
      with channel type, userspace can't be relying on it.
      This is the case, as it's used only for P2P operations
      right now.
      
      Rather than adding a flag to tell userspace whether or
      not it can actually rely on it, simplify all the code
      by removing the ability to use different channel types.
      Leave only the validation of the attribute, so that if
      we extend it again later (with the needed capability
      flag), it can't break userspace sending invalid data.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      42d97a59
  11. 18 10月, 2012 2 次提交
  12. 17 10月, 2012 1 次提交
  13. 15 10月, 2012 1 次提交
  14. 19 9月, 2012 1 次提交
  15. 11 9月, 2012 1 次提交
  16. 20 8月, 2012 1 次提交
    • J
      cfg80211: add P2P Device abstraction · 98104fde
      Johannes Berg 提交于
      In order to support using a different MAC address
      for the P2P Device address we must first have a
      P2P Device abstraction that can be assigned a MAC
      address.
      
      This abstraction will also be useful to support
      offloading P2P operations to the device, e.g.
      periodic listen for discoverability.
      
      Currently, the driver is responsible for assigning
      a MAC address to the P2P Device, but this could be
      changed by allowing a MAC address to be given to
      the NEW_INTERFACE command.
      
      As it has no associated netdev, a P2P Device can
      only be identified by its wdev identifier but the
      previous patches allowed using the wdev identifier
      in various APIs, e.g. remain-on-channel.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      98104fde
  17. 17 7月, 2012 1 次提交
  18. 09 7月, 2012 1 次提交
    • J
      cfg80211: use wdev in mgmt-tx/ROC APIs · 71bbc994
      Johannes Berg 提交于
      The management frame and remain-on-channel APIs will be
      needed in the P2P device abstraction, so move them over
      to the new wdev-based APIs. Userspace can still use both
      the interface index and wdev identifier for them so it's
      backward compatible, but for the P2P Device wdev it will
      be able to use the wdev identifier only.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      71bbc994
  19. 29 6月, 2012 2 次提交
  20. 07 6月, 2012 1 次提交
  21. 10 5月, 2012 1 次提交
    • J
      wireless: Convert compare_ether_addr to ether_addr_equal · ac422d3c
      Joe Perches 提交于
      Use the new bool function ether_addr_equal to add
      some clarity and reduce the likelihood for misuse
      of compare_ether_addr for sorting.
      
      I removed a conversion from scan.c/cmp_bss_core
      that appears to be a sorting function.
      
      Done via cocci script:
      
      $ cat compare_ether_addr.cocci
      @@
      expression a,b;
      @@
      -	!compare_ether_addr(a, b)
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	compare_ether_addr(a, b)
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) == 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) != 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) == 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) != 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!!ether_addr_equal(a, b)
      +	ether_addr_equal(a, b)
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ac422d3c
  22. 12 4月, 2012 1 次提交
  23. 10 4月, 2012 1 次提交
  24. 07 3月, 2012 1 次提交
  25. 01 3月, 2012 1 次提交
  26. 07 2月, 2012 1 次提交
    • J
      cfg80211: stop tracking authenticated state · 95de817b
      Johannes Berg 提交于
      To track authenticated state seems to have been
      a design mistake in cfg80211. It is possible to
      have out of band authentication (FT), tracking
      multiple authentications caused more problems
      than it ever helped, and the implementation in
      mac80211 is too complex.
      
      Remove all this complexity, and let userspace
      do whatever it wants to, mac80211 can deal with
      that just fine. Association is still tracked of
      course, but authentication no longer is. Local
      auth state changes are thus no longer of value,
      so ignore them completely.
      
      This will also help implement SAE -- asking the
      driver to do an authentication is now almost
      equivalent to sending an authentication frame,
      with the exception of shared key authentication
      which is still handled completely.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      95de817b
  27. 22 11月, 2011 1 次提交
    • B
      wireless: Support ht-capabilities over-rides. · 7e7c8926
      Ben Greear 提交于
      This allows users to disable features such as HT, HT40,
      and to modify the MCS, AMPDU, and AMSDU settings for
      drivers that support it.
      
      The MCS, AMPDU, and AMSDU features that may be disabled are
      are reported in the phy-info netlink message as a mask.
      
      Attemping to disable features that are not supported will
      take no affect, but will not return errors.  This is to aid
      backwards compatibility in user-space apps that may not be
      clever enough to deal with parsing the the capabilities mask.
      
      This patch only enables the infrastructure.  An additional
      patch will enable the feature in mac80211.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7e7c8926
  28. 10 11月, 2011 3 次提交
  29. 28 9月, 2011 1 次提交
  30. 20 9月, 2011 1 次提交