1. 17 9月, 2010 4 次提交
  2. 15 9月, 2010 7 次提交
  3. 08 9月, 2010 5 次提交
  4. 01 9月, 2010 1 次提交
  5. 28 8月, 2010 2 次提交
  6. 25 8月, 2010 2 次提交
  7. 17 8月, 2010 8 次提交
  8. 14 8月, 2010 2 次提交
  9. 12 8月, 2010 1 次提交
    • R
      ath9k_htc: fix panic on packet injection using airbase-ng tool. · da93f106
      Rajkumar Manoharan 提交于
      This should fix the oops which occurs during the packet injection
      on monitor interface.
      
      EIP is at ath9k_htc_tx_start+0x69/0x220 [ath9k_htc]
       [<f84dc8ea>] ? invoke_tx_handlers+0xa5a/0xee0 [mac80211]
       [<f82c84f4>] ? ath9k_htc_tx+0x44/0xe0 [ath9k_htc]
       [<f84db7b8>] ? __ieee80211_tx+0xf8/0x190 [mac80211]
       [<f84dce0d>] ? ieee80211_tx+0x9d/0x1a0 [mac80211]
       [<f84dcfac>] ? ieee80211_xmit+0x9c/0x1c0 [mac80211]
       [<f84dd1b5>] ? ieee80211_monitor_start_xmit+0x85/0xb0 [mac80211]
       [<c04c30cd>] ? dev_hard_start_xmit+0x1ad/0x210
       [<c04b97c2>] ? __alloc_skb+0x52/0x130
       [<c04d7cd5>] ? sch_direct_xmit+0x105/0x170
       [<c04c5e9f>] ? dev_queue_xmit+0x37f/0x4b0
       [<c0567e1e>] ? packet_snd+0x21e/0x250
       [<c05684a2>] ? packet_sendmsg+0x32/0x40
       [<c04b4c63>] ? sock_aio_write+0x113/0x130
       [<c0207934>] ? do_sync_write+0xc4/0x100
       [<c0167740>] ? autoremove_wake_function+0x0/0x50
       [<c02f4414>] ? security_file_permission+0x14/0x20
       [<c0207ad4>] ? rw_verify_area+0x64/0xe0
       [<c01e6458>] ? handle_mm_fault+0x338/0x390
       [<c0207cd5>] ? vfs_write+0x185/0x1a0
       [<c058db20>] ? do_page_fault+0x160/0x3a0
       [<c0208512>] ? sys_write+0x42/0x70
       [<c01033ec>] ? syscall_call+0x7/0xb
      Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      da93f106
  10. 05 8月, 2010 8 次提交
    • J
      ath9k: fix erased ieee80211_rx_status.mactime · c8f3b721
      Jan Friedrich 提交于
      ath9k_rx_skb_preprocess nulls rxs and the mactime is never set again -
      mactime is always 0. This causes problems in IBSS mode.
      
      ieee80211_rx_bss_info uses mactime to decide if an IBSS merge is needed.
      Without this patch the merge is triggered by each beacon received.
      
      This can be recognized by the "beacon TSF higher than local TSF - IBSS
      merge with BSSID" log message accompanying each beacon.
      
      This problem was not completely fixed in commit
      a6d2055b and is not a stable kernel fix.
      It is solely intended for wireless-testing.
      Signed-off-by: NJan Friedrich <jft@dev2day.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c8f3b721
    • L
      ath9k: fix an issue in ath_atx_tid paused flag management · 75401849
      Lorenzo Bianconi 提交于
      I noticed a possible issue in the paused flag management of the
      ath_atx_tid data structure. In particular, in a noisy environment and
      under heavy load, I observed that the AGGR session establishment could
      fail several times consecutively causing values of the paused flag
      greater than one for this TID (ath_tx_pause_tid is called more than
      once from ath_tx_aggr_start).
      
      Considering that the session for this TID can not be established also
      after the mac80211 stack calls the ieee80211_agg_tx_operational() since
      the ath_tx_aggr_resume() lowers the paused flag only by one.
      
      This patch also replaces some BUG_ON calls with WARN_ON, as even if
      these unlikely conditions happen, it's not fatal enough to justify a
      BUG_ON.
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi83@gmail.com>
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      75401849
    • L
      ath9k_hw: Fix regulatory CTL index usage for AR9003 · 824b185a
      Luis R. Rodriguez 提交于
      AR9003 was not relying on the CTL indexes from the EEPROM for capping the
      max output power. The CTL indexes from the EEPROM provide calibrated
      limits for output power for each tested and supported frequency. Without
      this the device operates at a power level which only conforms to the
      transmit spectrum mask as specified by IEEE Annex I.2.3.
      
      The regulatory limit by CRDA is always used but does not provide
      calibrated values for optimal performance, specially on band edges.
      Using the calibrated data from the EEPROM ensures the device
      operates at optimal output power while still ensuring proper
      regulatory compliance. The device uses the minimum of these tree
      values, the value from CRDA, the calibrated value from CTL indexex,
      and the value to conform to the IEEE transmit spectrum mask.
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      824b185a
    • F
      ath9k_hw: fix a noise floor calibration related race condition · 4254bc1c
      Felix Fietkau 提交于
      On AR5008-AR9002, other forms of calibration must not be started while
      the noise floor calibration is running, as this can create invalid
      readings which were sometimes not even recoverable by any further
      calibration attempts.
      
      This patch also ensures that the result of noise floor measurements
      are processed faster and also allows the result of the initial
      calibration on reset to make it into the NF history buffer
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4254bc1c
    • F
      ath9k_hw: clean up per-channel calibration data · 20bd2a09
      Felix Fietkau 提交于
      The noise floor history buffer is currently not kept per channel, which
      can lead to problems when changing channels from a clean channel to a
      noisy one. Also when switching from HT20 to HT40, the noise floor
      history buffer is full of measurements, but none of them contain data
      for the extension channel, which it needs quite a bit of time to recover
      from.
      
      This patch puts all the per-channel calibration data into a single data
      structure, and gives the the driver control over whether that is used
      per-channel or even not used for some channels.
      
      For ath9k_htc, I decided to keep this per-channel in order to avoid
      creating regressions.
      
      For ath9k, the data is kept only for the operating channel, which saves
      some space. ath9k_hw takes care of wiping old data when the operating
      channel or its channel flags change.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      20bd2a09
    • F
      ath9k: prevent calibration during off-channel activity · 5ee08656
      Felix Fietkau 提交于
      Previously the software scan callback was used to indicate to the hardware,
      when it was safe to calibrate. This didn't really work properly, because it
      depends on a specific order of software scan callbacks vs. channel changes.
      Also, software scans are not the only thing that triggers off-channel
      activity, so it's better to use the newly added indication from mac80211 for
      this and not use the software scan callback for anything calibration related.
      
      This fixes at least some of the invalid noise floor readings that I've seen
      in AP mode on AR9160
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5ee08656
    • F
      ath9k_hw: fix analog shift register writes on AR9003 · b2ccc507
      Felix Fietkau 提交于
      Writes to the analog shift registers, which are issues by the initval
      programming function, require a 100 usec delay (similar to AR9002,
      but in a different register range).
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b2ccc507
    • F
      ath9k: fix a crash in the PA predistortion apply function · ddfef792
      Felix Fietkau 提交于
      When updating the PAPRD table in hardware, PAPRD itself needs to be
      disabled first, otherwise the hardware can throw a data bus error,
      which upsets at least some platforms.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ddfef792