Skip to content

L
linux
Switch branch/tag
  1. 26 Apr, 2011 7 commits
    • Christian Lamparter's avatar
      p54: implement multicast filter · be8d98ea
      Christian Lamparter authored 
      "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: default avatarChristian Lamparter <chunkeey@googlemail.com>
Tested-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      be8d98ea
    • Rafał Miłecki's avatar
      ssb: update reject bit for Target State Low · 04ad1fb2
      Rafał Miłecki authored 
      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: default avatarRafał Miłecki <zajec5@gmail.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      04ad1fb2
    • Rafał Miłecki's avatar
      ssb: mark bus as powered up earlier · a6ef8143
      Rafał Miłecki authored 
      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: default avatarRafał Miłecki <zajec5@gmail.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a6ef8143
    • Adrian Chadd's avatar
      ath9k: fix AR9160 xpaBiasLvlFreq endianness handling · 25f63a5a
      Adrian Chadd authored 
      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: default avatarAdrian Chadd <adrian@freebsd.org>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      25f63a5a
    • Rajkumar Manoharan's avatar
      ath9k: set beacon related ps flags on bss_info change · 92c6f76c
      Rajkumar Manoharan authored 
      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: default avatarRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      92c6f76c
    • Rajkumar Manoharan's avatar
      ath9k_hw: Fix Tx IQ Calibration hang issue in AR9003 chips · 3782c69d
      Rajkumar Manoharan authored 
      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: default avatarRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3782c69d
    • John W. Linville's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 · 429576b9
      John W. Linville authored
      429576b9
  3. 25 Apr, 2011 33 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7