1. 05 12月, 2008 3 次提交
  2. 22 11月, 2008 3 次提交
  3. 19 11月, 2008 1 次提交
    • J
      mac80211: remove ieee80211_notify_mac · 8e3bad65
      Johannes Berg 提交于
      Before ieee80211_notify_mac() was added, it was presented with the
      use case of using it to tell mac80211 that the association may
      have been lost because the firmware crashed/reset.
      
      Since then, it has also been used by iwlwifi to (slightly) speed
      up re-association after resume, a workaround around the fact that
      mac80211 has no suspend/resume handling yet. It is also not used
      by any other drivers, so clearly it cannot be necessary for "good
      enough" suspend/resume.
      
      Unfortunately, the callback suffers from a severe problem: It only
      works for station mode. If suspend/resume happens while in IBSS or
      any other mode (but station), then the callback is pointless.
      
      Recently, it has created a number of locking issues, first because
      it required rtnl locking rather than RCU due to calling sleeping
      functions within the critical section, and now because it's called
      by iwlwifi from the mac80211 workqueue that may not use the rtnl
      because it is flushed under rtnl.
      (cf. http://bugzilla.kernel.org/show_bug.cgi?id=12046)
      
      I think, therefore, that we should take a step back, remove it
      entirely for now and add the small feature it provided properly.
      For suspend and resume we will need to introduce new hooks, and for
      the case where the firmware was reset the driver will probably
      simply just pretend it has done a suspend/resume cycle to get
      mac80211 to reprogram the hardware completely, not just try to
      connect to the current AP again in station mode. When doing so, we
      will need to take into account locking issues and possibly defer
      to schedule_work from within mac80211 for the resume operation,
      while the suspend operation must be done directly.
      
      Proper suspend/resume should also not necessarily try to reconnect
      to the current AP, the time spent in suspend may have been short
      enough to not be disconnected from the AP, mac80211 will detect
      that the AP went out of range quickly if it did, and if the
      association is lost then the AP will disassoc as soon as a data
      frame is sent. We might also take into account WWOL then, and
      have mac80211 program the hardware into such a mode where it is
      available and requested.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8e3bad65
  4. 11 11月, 2008 2 次提交
  5. 01 11月, 2008 14 次提交
  6. 28 10月, 2008 1 次提交
    • R
      mac80211.h: fix kernel-doc excesses · ea2d8b59
      Randy Dunlap 提交于
      Fix mac80211.h kernel-doc: it had some extra parameters that were
      no longer valid and incorrect format for a return value in 2 places.
      
      Warning(lin2628-rc2//include/net/mac80211.h:1487): Excess function parameter or struct member 'control' description in 'ieee80211_beacon_get'
      Warning(lin2628-rc2//include/net/mac80211.h:1596): Excess function parameter or struct member 'control' description in 'ieee80211_get_buffered_bc'
      Warning(lin2628-rc2//include/net/mac80211.h:1632): Excess function parameter or struct member 'rc4key' description in 'ieee80211_get_tkip_key'
      Warning(lin2628-rc2//include/net/mac80211.h:1735): Excess function parameter or struct member 'return' description in 'ieee80211_start_tx_ba_session'
      Warning(lin2628-rc2//include/net/mac80211.h:1775): Excess function parameter or struct member 'return' description in 'ieee80211_stop_tx_ba_session'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ea2d8b59
  7. 15 10月, 2008 1 次提交
  8. 07 10月, 2008 2 次提交
  9. 25 9月, 2008 1 次提交
    • J
      mac80211: clean up rate control API · 4b7679a5
      Johannes Berg 提交于
      Long awaited, hard work. This patch totally cleans up the rate control
      API to remove the requirement to include internal headers outside of
      net/mac80211/.
      
      There's one internal use in the PID algorithm left for mesh networking,
      we'll have to figure out a way to clean that one up and decide how to
      do the peer link evaluation, possibly independent of the rate control
      algorithm or via new API.
      
      Additionally, ath9k is left using the cross-inclusion hack for now, we
      will add new API where necessary to make this work properly, but right
      now I'm not expert enough to do it. It's still off better than before.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4b7679a5
  10. 16 9月, 2008 8 次提交
    • J
      mac80211: fix virtual interfaces vs. injection · 25d834e1
      Johannes Berg 提交于
      Currently, virtual interface pointers passed to drivers might be
      from monitor interfaces and as such completely uninitialised
      because we do not tell the driver about monitor interfaces when
      those are created. Instead of passing them, we should therefore
      indicate to the driver that there is no information; do that by
      passing a NULL value and adjust drivers to cope with it.
      
      As a result, some mac80211 API functions also need to cope with
      a NULL vif pointer so drivers can still call them unconditionally.
      
      Also, when injecting frames we really don't want to pass NULL all
      the time, if we know we are the source address of a frame and have
      a local interface for that address, we can to use that interface.
      This also helps with processing the frame correctly for that
      interface which will help the 802.11w implementation. It's not
      entirely correct for VLANs or WDS interfaces because there the MAC
      address isn't unique, but it's already a lot better than what we
      do now.
      
      Finally, when injecting without a matching local interface, don't
      assign sequence numbers at all.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      25d834e1
    • J
      mac80211: share sta_info->ht_info · 687c7c08
      Johannes Berg 提交于
      Rate control algorithms may need access to a station's
      HT capabilities, so share the ht_info struct in the
      public station API.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      687c7c08
    • J
      mac80211: share sta->supp_rates · 323ce79a
      Johannes Berg 提交于
      As more preparation for a saner rate control algorithm API,
      share the supported rates bitmap in the public API.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      323ce79a
    • J
      mac80211: share STA information with driver · 17741cdc
      Johannes Berg 提交于
      This patch changes mac80211 to share some more data about
      stations with drivers. Should help iwlwifi and ath9k when
       they get around to updating, and might also help with
      implementing rate control algorithms without internals.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: Sujith Manoharan <Sujith.Manoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      17741cdc
    • J
      mac80211: use nl80211 interface types · 05c914fe
      Johannes Berg 提交于
      There's really no reason for mac80211 to be using its
      own interface type defines. Use the nl80211 types and
      simplify the configuration code a bit: there's no need
      to translate them any more now.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      05c914fe
    • J
      mac80211: inform driver of basic rateset · 96dd22ac
      Johannes Berg 提交于
      Drivers need to know the basic rateset to be able to configure
      the ACK/CTS programming in hardware correctly.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      96dd22ac
    • J
      mac80211: fix scan vs. interface removal race · 5bc75728
      Johannes Berg 提交于
      When we remove an interface, we can currently end up having
      a pointer to it left in local->scan_sdata after it has been
      set down, and then with a hardware scan the scan completion
      can try to access it which is a bug. Alternatively, a scan
      that started as a hardware scan may terminate as though it
      was a software scan, if the timing is just right.
      
      On SMP systems, software scan also has a similar problem,
      just canceling the delayed work and setting a flag isn't
      enough since it may be running concurrently; in this case
      we would also never restore state of other interfaces.
      
      This patch hopefully fixes the problems by always invoking
      ieee80211_scan_completed or requiring it to be invoked by
      the driver, I suspect the drivers that have ->hw_scan() are
      buggy. The bug will not manifest itself unless you remove
      the interface while hw-scanning which will also turn off
      the hw, and then add a new interface which will be unusable
      until you scan once.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5bc75728
    • L
      cfg80211: Add new wireless regulatory infrastructure · b2e1b302
      Luis R. Rodriguez 提交于
      This adds the new wireless regulatory infrastructure. The
      main motiviation behind this was to centralize regulatory
      code as each driver was implementing their own regulatory solution,
      and to replace the initial centralized code we have where:
      
      * only 3 regulatory domains are supported: US, JP and EU
      * regulatory domains can only be changed through module parameter
      * all rules were built statically in the kernel
      
      We now have support for regulatory domains for many countries
      and regulatory domains are now queried through a userspace agent
      through udev allowing distributions to update regulatory rules
      without updating the kernel.
      
      Each driver can regulatory_hint() a regulatory domain
      based on either their EEPROM mapped regulatory domain value to a
      respective ISO/IEC 3166-1 country code or pass an internally built
      regulatory domain. We also add support to let the user set the
      regulatory domain through userspace in case of faulty EEPROMs to
      further help compliance.
      
      Support for world roaming will be added soon for cards capable of
      this.
      
      For more information see:
      
      http://wireless.kernel.org/en/developers/Regulatory/CRDA
      
      For now we leave an option to enable the old module parameter,
      ieee80211_regdom, and to build the 3 old regdomains statically
      (US, JP and EU). This option is CONFIG_WIRELESS_OLD_REGULATORY.
      These old static definitions and the module parameter is being
      scheduled for removal for 2.6.29. Note that if you use this
      you won't make use of a world regulatory domain as its pointless.
      If you leave this option enabled and if CRDA is present and you
      use US or JP we will try to ask CRDA to update us a regulatory
      domain for us.
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b2e1b302
  11. 12 9月, 2008 1 次提交
  12. 30 8月, 2008 1 次提交
  13. 23 8月, 2008 2 次提交