1. 25 Oct, 2010 11 commits
    • Felix Fietkau's avatar
      ath9k: fix handling of rate control probe frames · 0299a50a
      Felix Fietkau authored
      The ath9k aggregation code was already checking the rate control probe flag
      to prevent starting an aggregate frame with a sampling rate. What was missing
      was closing an aggregate before adding a probing frame to it.
      Without that, rate control cannot have precise control over probing, which
      delays using faster rates when the channel conditions improve.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0299a50a
    • Felix Fietkau's avatar
      ath9k: fix crash in ath_update_survey_stats · 0845735e
      Felix Fietkau authored
      If ah->curchan is uninitialized, the channel index is bogus, which leads
      to invalid memory access when the cycle counters are updated.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0845735e
    • Senthil Balasubramanian's avatar
      ath9k_hw: Fix divide by zero cases in paprd. · 2d3fca18
      Senthil Balasubramanian authored
      We are not handling all divide by zero cases in paprd.
      Add additional checks for divide by zero cases in papard.
      
      This patch has fixes intended for kernel 2.6.36.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2d3fca18
    • Luis R. Rodriguez's avatar
      ath9k_hw: Fix TX carrier leakage for IEEE compliance on AR9003 2.2 · 0dfa6dbb
      Luis R. Rodriguez authored
      This updates the initvals for the AR9003 2.2 chipsets. The initvals
      are the initial register values we use for our registers upon hardware
      reset. This synchs up the initvals to match what our latest recommendation
      from our systems engineering team.
      
      The description of changes in this update:
      
              Improves ability to support very strong Rx conditions.
              Enhances DFS support for AP-mode.
              Improves performance of Tx carrier leak calibration.
              Adds support for Japan channel 14 Tx filtering requirements.
              Improves Tx power accuracy.
      
      Impact:
      
              Update required to address degraded throughput at very short range.
              Update required for AP-mode DFS certification.
              Update required to comply to IEEE Tx carrier leak specification.
              May not meet expected +/- 2 dB Tx power accuracy without update.
      
      The most important fix here would be the TX carrier leakage required
      to comply with IEEE 802.11 specifications. The group of changes have
      been tested all together in one release.
      
      References:
      
      	Osprey 2.2 header file ver #33
      
      Checksums:
      
      $ ./initvals -f ar9003-2p2
      0x000000004a488fc7        ar9300_2p2_radio_postamble
      0x0000000046cb1300        ar9300Modes_lowest_ob_db_tx_gain_table_2p2
      0x00000000e912711f        ar9300Modes_fast_clock_2p2
      0x0000000037ac0ee8        ar9300_2p2_radio_core
      0x00000000047a7700        ar9300Common_rx_gain_table_merlin_2p2
      0x0000000003f783bb        ar9300_2p2_mac_postamble
      0x00000000301fc841        ar9300_2p2_soc_postamble
      0x000000005ec8075f        ar9200_merlin_2p2_radio_core
      0x0000000083372ffa        ar9300_2p2_baseband_postamble
      0x00000000c4f59974        ar9300_2p2_baseband_core
      0x00000000e20d2e72        ar9300Modes_high_power_tx_gain_table_2p2
      0x000000007fd55c70        ar9300Modes_high_ob_db_tx_gain_table_2p2
      0x0000000029495000        ar9300Common_rx_gain_table_2p2
      0x0000000042cb1300        ar9300Modes_low_ob_db_tx_gain_table_2p2
      0x00000000c4739cd6        ar9300_2p2_mac_core
      0x000000003521a300        ar9300Common_wo_xlna_rx_gain_table_2p2
      0x00000000a15ccf1b        ar9300_2p2_soc_preamble
      0x0000000029734396        ar9300PciePhy_pll_on_clkreq_disable_L1_2p2
      0x000000002d834396        ar9300PciePhy_clkreq_enable_L1_2p2
      0x0000000029834396        ar9300PciePhy_clkreq_disable_L1_2p2
      
      $ ./initvals -f ar9003-2p2 | sha1sum
      0ceddb5cf66737610fb51f04cf3e9ff71870c7b4  -
      
      Cc: stable@kernel.org
      Cc: Yixiang Li <yixiang.li@atheros.com>
      Cc: Don Breslin <don.breslin@atheros.com>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0dfa6dbb
    • Luis R. Rodriguez's avatar
      cfg80211: fix regression on processing country IEs · a171fba4
      Luis R. Rodriguez authored
      The patch 4f366c5d:
      
      	wireless: only use alpha2 regulatory information from country IE
      
      removed some complex intersection we were always doing between the AP's
      country IE info and what we got from CRDA. When CRDA sent us back a
      regulatory domain we would do some sanity checks on that regulatory
      domain response we just got. Part of these sanity checks included
      checking that we already had performed an intersection for the
      request of NL80211_REGDOM_SET_BY_COUNTRY_IE type.
      
      This mean that cfg80211 was only processing country IEs for cases
      where we already had an intersection, but since we removed enforcing
      this this is no longer required, we should just apply the country
      IE country hint with the data received from CRDA.
      
      This patch has fixes intended for kernels >= 2.6.36.
      
      Cc: stable@kernel.org
      Reported-by: default avatarEaswar Krishnan <easwar.krishnan@atheros.com>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a171fba4
    • Christian Lamparter's avatar
      carl9170: fix memory leak issue in async cmd macro wrappers · 3d2f2cd0
      Christian Lamparter authored
      This patch continues where the previous commit:
      	"carl9170: fix async command buffer leak"
      left off.
      
      Similar to carl9170_reboot/carl9170_powersave, the
      carl9170_async_regwrite* macros would leak the
      temporary command buffer, if __carl9170_exec_cmd
      fails to upload the command to the device.
      Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3d2f2cd0
    • Christian Lamparter's avatar
      mac80211: don't sanitize invalid rates · 5f4e6b2d
      Christian Lamparter authored
      I found this bug while poking around with a pure-gn AP.
      
      Commit:
      cfg80211/mac80211: Use more generic bitrate mask for rate control
      
      Added some sanity checks to ensure that each tx rate index
      is included in the configured mask and it would change any
      rate indexes if it wasn't.
      
      But, the current implementation doesn't take into account
      that the invalid rate index "-1" has a special meaning
      (= no further attempts) and it should not be "changed".
      Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5f4e6b2d
    • Christian Lamparter's avatar
      carl9170: fix async command buffer leak · cae7f953
      Christian Lamparter authored
      If __carl9170_exec_cmd fails to upload an asynchronous
      command to the device, the functions: carl9170_reboot
      and carl9170_powersave will leak the temporary command
      assembly buffer.
      Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      cae7f953
    • Ben Greear's avatar
      ath5k: Properly initialize ath_common->cc_lock. · 9192f715
      Ben Greear authored
      Otherwise, lockdep splats, at the least:
      
      INFO: trying to register non-static key.
      the code is fine but needs lockdep annotation.
      turning off the locking correctness validator.
      Pid: 0, comm: swapper Not tainted 2.6.36-rc8-wl+ #32
      Call Trace:
       [<c075d940>] ? printk+0xf/0x17
       [<c045507a>] register_lock_class+0x5a/0x29e
       [<c0456af5>] __lock_acquire+0xa2/0xb8c
       [<c0455be2>] ? mark_lock+0x1e/0x1de
       [<c041a540>] ? acpi_get_override_irq+0x85/0x8c
       [<c0455536>] ? trace_hardirqs_off+0xb/0xd
       [<c0457639>] lock_acquire+0x5a/0x78
       [<f8126835>] ? ath5k_ani_calibration+0x24/0x52b [ath5k]
       [<c075f6ed>] _raw_spin_lock_bh+0x20/0x2f
       [<f8126835>] ? ath5k_ani_calibration+0x24/0x52b [ath5k]
       [<f8126835>] ath5k_ani_calibration+0x24/0x52b [ath5k]
       [<c0438f99>] ? tasklet_action+0x3b/0xc6
       [<f8123c2b>] ath5k_tasklet_ani+0x18/0x22 [ath5k]
       [<c0438fd1>] tasklet_action+0x73/0xc6
       [<c043945f>] __do_softirq+0x86/0x111
       [<c0439520>] do_softirq+0x36/0x5a
       [<c0439659>] irq_exit+0x35/0x69
       [<c0403fb9>] do_IRQ+0x86/0x9a
       [<c04034ee>] common_interrupt+0x2e/0x40
       [<c045007b>] ? do_adjtimex+0x223/0x55e
       [<c0408245>] ? mwait_idle+0x5c/0x6c
       [<c040227f>] cpu_idle+0x4e/0x6b
       [<c074b6e9>] rest_init+0x8d/0x92
       [<c09758ea>] start_kernel+0x320/0x325
       [<c09750d0>] i386_start_kernel+0xd0/0xd7
      Signed-off-by: default avatarBen Greear <greearb@candelatech.com>
      Acked-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9192f715
    • Ben Greear's avatar
      ath9k: Properly initialize ath_common->cc_lock. · 20b25744
      Ben Greear authored
      Otherwise, lockdep splats, at the least:
      
      INFO: trying to register non-static key.
      the code is fine but needs lockdep annotation.
      turning off the locking correctness validator.
      Pid: 2240, comm: ip Not tainted 2.6.36-rc8-wl+ #32
      Call Trace:
       [<c075d940>] ? printk+0xf/0x17
       [<c045507a>] register_lock_class+0x5a/0x29e
       [<c0455be2>] ? mark_lock+0x1e/0x1de
       [<c0456af5>] __lock_acquire+0xa2/0xb8c
       [<c0455be2>] ? mark_lock+0x1e/0x1de
       [<c0457639>] lock_acquire+0x5a/0x78
       [<f8c5115b>] ? ath9k_config+0x274/0x3d8 [ath9k]
       [<c075f602>] _raw_spin_lock_irqsave+0x2f/0x3f
       [<f8c5115b>] ? ath9k_config+0x274/0x3d8 [ath9k]
       [<f8c5115b>] ath9k_config+0x274/0x3d8 [ath9k]
       [<f8c0ba2e>] ieee80211_hw_config+0x11b/0x125 [mac80211]
       [<f8c17edf>] ieee80211_do_open+0x3c5/0x466 [mac80211]
       [<f8c171d6>] ? ieee80211_check_concurrent_iface+0x21/0x13a [mac80211]
       [<f8c17fdb>] ieee80211_open+0x5b/0x5e [mac80211]
       [<c06ce76b>] __dev_open+0x80/0xae
       [<c06cc99b>] __dev_change_flags+0xa0/0x115
       [<c06ce6bf>] dev_change_flags+0x13/0x3f
       [<c06d7e78>] do_setlink+0x23a/0x51b
       [<c0455037>] ? register_lock_class+0x17/0x29e
       [<c06d847c>] rtnl_newlink+0x269/0x431
       [<c06d8291>] ? rtnl_newlink+0x7e/0x431
       [<c0455be2>] ? mark_lock+0x1e/0x1de
       [<c0455de9>] ? mark_held_locks+0x47/0x5f
       [<c075ebcf>] ? __mutex_lock_common+0x2bb/0x2d6
       [<c0456045>] ? trace_hardirqs_on_caller+0x104/0x125
       [<c075ebe0>] ? __mutex_lock_common+0x2cc/0x2d6
       [<c06d8213>] ? rtnl_newlink+0x0/0x431
       [<c06d79e2>] rtnetlink_rcv_msg+0x182/0x198
       [<c06d7860>] ? rtnetlink_rcv_msg+0x0/0x198
       [<c06e503c>] netlink_rcv_skb+0x30/0x77
       [<c06d7859>] rtnetlink_rcv+0x1b/0x22
       [<c06e4e77>] netlink_unicast+0xbe/0x119
       [<c06e5a15>] netlink_sendmsg+0x234/0x24c
       [<c06bf93a>] __sock_sendmsg+0x51/0x5a
       [<c06bfba4>] sock_sendmsg+0x93/0xa7
       [<c04968cf>] ? might_fault+0x47/0x81
       [<c0496904>] ? might_fault+0x7c/0x81
       [<c06c7904>] ? copy_from_user+0x8/0xa
       [<c06c7c2d>] ? verify_iovec+0x3e/0x6d
       [<c06bfd8c>] sys_sendmsg+0x149/0x193
       [<c0455037>] ? register_lock_class+0x17/0x29e
       [<c0455be2>] ? mark_lock+0x1e/0x1de
       [<c0498d7a>] ? __do_fault+0x1fc/0x3a5
       [<c048690a>] ? unlock_page+0x40/0x43
       [<c0498ef7>] ? __do_fault+0x379/0x3a5
       [<c04576dd>] ? lock_release_non_nested+0x86/0x1d8
       [<c04968cf>] ? might_fault+0x47/0x81
       [<c04968cf>] ? might_fault+0x47/0x81
       [<c06c148b>] sys_socketcall+0x15e/0x1a5
       [<c0402f1c>] sysenter_do_call+0x12/0x38
      Signed-off-by: default avatarBen Greear <greearb@candelatech.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      20b25744
    • Tejun Heo's avatar
      mac80211: cancel restart_work explicitly instead of depending on flush_scheduled_work() · 99b88a0e
      Tejun Heo authored
      iee80211_hw->restart_work is the only work which uses the system
      workqueue.  Instead of calling flush_scheduled_work() during
      iee80211_exit(), cancel the work during unregistration.
      
      This is to prepare for the deprecation and removal of
      flush_scheduled_work().
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      99b88a0e
  2. 24 Oct, 2010 29 commits