1. 12 10月, 2010 2 次提交
  2. 08 10月, 2010 3 次提交
  3. 07 10月, 2010 13 次提交
  4. 06 10月, 2010 17 次提交
  5. 29 9月, 2010 3 次提交
    • J
      mac80211: Fix WMM driver queue configuration · f2176d72
      Juuso Oikarinen 提交于
      The WMM parameter configuration function (ieee80211_sta_wmm_params) only
      configures the WMM parameters to the driver is the wmm_last_param_set
      counter value is changed by the AP.
      
      The wmm_last_param_set is initialized to -1 on association in order to ensure
      the configuration is made to the driver at least once on association, but
      currently this initialization is done *after* the WMM parameter configuration
      function was called.
      
      This leads to unreliability in the driver getting properly configured on first
      association (depending on what counter value the AP happens to use.) When
      disassociating (the wmm default parameters are configured to the driver) and
      then reassociating, due to the above the WMM configuration is not set to the
      driver at all.
      
      On drivers without beacon filtering the problem is corrected by later beacons,
      but on drivers with beacon filtering the WMM will remain permanently incorrectly
      configured.
      
      Fix this by moving the initialization of wmm_last_param_set to -1 before
      ieee80211_sta_wmm_params is called on association.
      Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f2176d72
    • J
      cfg80211: always set IBSS basic rates · 93b05238
      Johannes Berg 提交于
      IBSS started from wireless extensions is currently
      missing basic rate configuration, fix this by moving
      the code to generate the default to the common code
      that gets invoked for both nl80211 and wext.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      93b05238
    • L
      mac80211: fix offchannel assumption upon association · 8d4780eb
      Luis R. Rodriguez 提交于
      Association is dealt with as an atomic offchannel operation,
      we do this because we don't know we are associated until we
      get the associatin response from the AP. When we do get the
      associatin response though we were never clearing the offchannel
      state. This has a few implications, we told drivers we were
      still offchannel, and the first configured TX power for the
      channel does not take into account any power constraints.
      
      For ath9k this meant ANI calibration would not start upon
      association, and we'd have to wait until the first bgscan
      to be triggered. There may be other issues this resolves
      but I'm too lazy to comb the code to check.
      
      Cc: stable@kernel.org
      Cc: Amod Bodas <amod.bodas@atheros.com>
      Cc: Vasanth Thiagarajan <vasanth.thiagarajan@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8d4780eb
  6. 28 9月, 2010 2 次提交
    • J
      mac80211: move packet flags into packet · 554891e6
      Johannes Berg 提交于
      commit 8c0c709e
      Author: Johannes Berg <johannes@sipsolutions.net>
      Date:   Wed Nov 25 17:46:15 2009 +0100
      
          mac80211: move cmntr flag out of rx flags
      
      moved the CMNTR flag into the skb RX flags for
      some aggregation cleanups, but this was wrong
      since the optimisation this flag tried to make
      requires that it is kept across the processing
      of multiple interfaces -- which isn't true for
      flags in the skb. The patch not only broke the
      optimisation, it also introduced a bug: under
      some (common!) circumstances the flag will be
      set on an already freed skb!
      
      However, investigating this in more detail, I
      found that most of the flags that we set should
      be per packet, _except_ for this one, due to
      a-MPDU processing. Additionally, the flags used
      for processing (currently just this one) need
      to be reset before processing a new packet.
      
      Since we haven't actually seen bugs reported as
      a result of the wrong flags handling (which is
      not too surprising -- the only real bug case I
      can come up with is an a-MSDU contained in an
      a-MPDU), I'll make a different fix for rc.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      554891e6
    • J
      mac80211: fix release_reorder_timeout in scan · 4080c7cd
      Johannes Berg 提交于
      Even if the reorder timeout timer fires while
      scanning, the frames weren't received during
      scanning and therefore shouldn't be dropped.
      To implement this, changes to the passive scan
      RX handler simplify understanding it, because
      it currently checks HW_SCANNING independently
      of a packet's in-scan receive status (which
      doesn't make a big difference, since scan_rx()
      will only pick up probe responses and beacons,
      which can't be aggregated.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4080c7cd