1. 27 4月, 2011 7 次提交
    • C
      carl9170: improve unicast PS buffering · caf1eae2
      Christian Lamparter 提交于
      Using the ieee80211_sta_block allows the PS code
      to handle awake->doze->awake transitions of our
      clients in a race-free manner.
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      caf1eae2
    • C
      p54: implement multicast filter · be8d98ea
      Christian Lamparter 提交于
      "For best CPU usage and power consumption, having as few
      frames as possible percolate through the stack is
      desirable. Hence, the hardware should filter as much
      as possible."
      
      Note: Not all firmwares include the multicast filter
      feature and the stack does not filter them either.
      The ARP filter on the other hand was dropped from the
      patch since it does not work correctly:
      
      Quote from: Max Filippov <jcmvbkbc@gmail.com>
      <http://www.spinics.net/lists/linux-wireless/msg67466.html>
      "In the ARP case, when there's no other traffic on p54spi,
      all ARP requests are dropped. But if there's some egress
      traffic from p54spi, filter seems to work correctly:
      only ARP requests that match filter pass through.
      
      In the multicast case filter seems to work correctly, but
      it treats broadcast as subject to that filtering too. By
      default only 01:00:5e:00:00:01 gets into priv->mc_maclist,
      so we miss all broadcasts.
      
      These two filters seem to interfere:
      - if we set ARP filter and multicast filter without bc
      	=>  we miss all ARPs if there's no egress traffic;
      - if we set ARP filter and multicast filter with bc or
      	don't set mc filter at all => we get all ARPs.
      
      This effect does not depend on filter setup order."
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Tested-by: NMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      be8d98ea
    • R
      ssb: update reject bit for Target State Low · 04ad1fb2
      Rafał Miłecki 提交于
      My 14e4:4315 is SSB_IDLOW_SSBREV_26:
      read32 0xfaafcff8 -> 0x600422d5
      My 14e4:4328 is SSB_IDLOW_SSBREV_24:
      read32 0xfaafcff8 -> 0x400422c5
      My 14e4:432b is SSB_IDLOW_SSBREV_26 again:
      read32 0xfaafcff8 -> 0x600422d5
      
      For all of them wl driver is using 0x2 reject bit:
      write32(0xf98) <- 0x00010002
      So it seems SSB 2.3 is the exception using another bit.
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      04ad1fb2
    • R
      ssb: mark bus as powered up earlier · a6ef8143
      Rafał Miłecki 提交于
      ssb_chipco_set_clockmode may want to touch CC registers to control power of the
      bus. However touching registers without powered_up set causes warnings.
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a6ef8143
    • A
      ath9k: fix AR9160 xpaBiasLvlFreq endianness handling · 25f63a5a
      Adrian Chadd 提交于
      The xpaBiasLvlFreq parameter array is made up of 16 bit words which
      aren't byte-swapped like the other 16-bit eeprom parameters are.
      It's only used by the AR9160.
      Signed-off-by: NAdrian Chadd <adrian@freebsd.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      25f63a5a
    • R
      ath9k: set beacon related ps flags on bss_info change · 92c6f76c
      Rajkumar Manoharan 提交于
      Requesting beacon sync up to configure beacon timers properly
      in hw, has be done after doing beacon config with default values.
      Setting the flags in beacon config is causing the device to not
      enter into network sleep on idle state.
      Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      92c6f76c
    • R
      ath9k_hw: Fix Tx IQ Calibration hang issue in AR9003 chips · 3782c69d
      Rajkumar Manoharan 提交于
      On AR9003 chips, doing three IQ calibrations will possibly cause chip
      in stuck state. In noisy environment, chip could receive
      a packet during the middle of three calibrations and it causes
      the conflict of HW access and the eventual failure. It also
      causes IQ calibration outliers which results in poor Tx EVM.
      
      The IQ Cal procedure is after resetting the chip, run IQ cal 3 times
      per each cal cycle and find the two closest readings and average of two.
      The advantage of running Tx IQ cal more than once is that we can compare
      calibration results for the same gain setting over multiple iterations.
      Most of the cases the IQ failures were observed after first pass.
      
      For the AR9485 and later chips, Tx IQ Calibration is performed along
      with AGC cal. But for pre-AR9485 chips, Tx IQ cal HW has to be separated
      from the rest of calibration HW to avoid chip hang. After all
      calibrations are done in HW, we can start SW post-processing.
      By doing this way, we minimize the SW difference among all chips.
      
      The order of calibration (run IQ cal before other calibration) is also
      needed to avoid chip hang for chips before AR9485. This issue was
      originally observed with AR9382.
      
      During the issue kernel log was filled with following message
      ath: timeout (100000 us) on reg 0xa640: 0x00000001 & 0x00000001 != 0x00000000
      ath: timeout (100000 us) on reg 0xa2c4: 0x00158dd9 & 0x00000001 != 0x00000000
      ath: Unable to reset channel (2412 MHz), reset status -5
      ath: Unable to set channel
      Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3782c69d
  2. 26 4月, 2011 33 次提交