1. 25 5月, 2013 1 次提交
  2. 23 4月, 2013 1 次提交
    • J
      mwl8k: remove nonstandard rate 72 Mbps · 3f524559
      Jonas Gorski 提交于
      This rate causes an overflow in the extended rates IE's data rate field,
      with the overflowing bit setting the Basic Rate Set membership. This
      results in a bogus 8 Mpbs basic rate, making clients checking them refuse
      association.
      
      Since the rate is likely unused anyway (HT will yield better rates between
      supporting chips), we can just remove it.
      
      This fixes association from wpa_supplicant and Android 4.x and newer.
      Signed-off-by: NJonas Gorski <jogo@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3f524559
  3. 28 3月, 2013 1 次提交
    • J
      mwl8k: always apply configuration even when device is idle · fe21bb02
      Jonas Gorski 提交于
      Fix settings not being applied when the device is idle and the firmware
      gets reloaded (because of changing from STA to AP mode). This caused
      the device using the wrong channel (and likely band), e.g. a 5 GHz only
      card still defaulted to channel 6 in the 2.4 GHz band when left
      unconfigured.
      
      This issue was always present, but only made visible with "mwl8k: Do not
      call mwl8k_cmd_set_rf_channel unconditionally" (0f4316b9), since before
      that the channel was (re-)configured at the next _config call even when
      it did not change from the mac80211 perspective.
      Signed-off-by: NJonas Gorski <jogo@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fe21bb02
  4. 26 3月, 2013 1 次提交
  5. 12 3月, 2013 1 次提交
    • J
      mwl8k: don't overwrite regulatory settings on fw reload · c3f251a3
      Jonas Gorski 提交于
      Currently the caps are parsed on every firmware reload, causing any
      channel flags to be cleared.
      When there is a firmware to interface mode mismatch, the triggered
      firmware reload causes a reset of the regulatory settings, causing all
      channels to become available:
      
      root@openrouter:/# iw phy phy0 info
      Wiphy phy0
              Band 1:
      		(...)
                      Frequencies:
                              * 2412 MHz [1] (0.0 dBm)
                              * 2417 MHz [2] (0.0 dBm)
                              * 2422 MHz [3] (0.0 dBm)
                              * 2427 MHz [4] (0.0 dBm)
                              * 2432 MHz [5] (0.0 dBm)
                              * 2437 MHz [6] (0.0 dBm)
                              * 2442 MHz [7] (0.0 dBm)
                              * 2447 MHz [8] (0.0 dBm)
                              * 2452 MHz [9] (0.0 dBm)
                              * 2457 MHz [10] (0.0 dBm)
                              * 2462 MHz [11] (0.0 dBm)
                              * 2467 MHz [12] (0.0 dBm)
                              * 2472 MHz [13] (0.0 dBm)
                              * 2484 MHz [14] (0.0 dBm)
      		(...)
      
      To prevent this, only parse the caps on the first firmware load during
      hardware probe, and store them locally to know we have already parsed
      them.
      Signed-off-by: NJonas Gorski <jogo@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c3f251a3
  6. 07 3月, 2013 2 次提交
  7. 12 2月, 2013 1 次提交
    • J
      mwl8k: fix band for supported channels · d786f67e
      Jonas Gorski 提交于
      The band field for the supported channels were left unpopulated, making
      them default to 0 == IEEE80211_BAND_2GHZ, even for the 5GHz channels.
      
      This resulted in null pointer accesses if anything tries to access
      wiphy->bands[channel->band] of a 5GHz channel on 5GHz only cards, since
      wiphy->bands[2GHZ] is NULL for them (e.g. cfg80211_chandef_usable does).
      
      Example kernel OOPS:
      
      [  665.669993] Unable to handle kernel NULL pointer dereference at virtual address 00000016
      [  665.678194] pgd = c6d58000
      [  665.680941] [00000016] *pgd=06f8a831, *pte=00000000, *ppte=00000000
      [  665.687303] Internal error: Oops: 17 [#1]
      (...)
      [  666.116373] Backtrace:
      [  666.118866] [<bf0368dc>] (cfg80211_chandef_usable+0x0/0x1bc [cfg80211]) from [<bf025e64>] (nl80211_leave_mesh+0x244/0x264 [cfg80211])
      [  666.130919]  r7:c6d12100 r6:0000143c r5:c0611c48 r4:c0611b98
      [  666.136668] [<bf025d84>] (nl80211_leave_mesh+0x164/0x264 [cfg80211]) from [<bf02634c>] (nl80211_remain_on_channel+0x2a0/0x358 [cfg80211])
      [  666.149074]  r7:c6d12000 r6:c6d12000 r5:c6f4f368 r4:00000003
      [  666.154814] [<bf0262ec>] (nl80211_remain_on_channel+0x240/0x358 [cfg80211]) from [<bf02ddb0>] (nl80211_set_wiphy+0x264/0x560 [cfg80211])
      [  666.167150] [<bf02db4c>] (nl80211_set_wiphy+0x0/0x560 [cfg80211]) from [<c01f94e0>] (genl_rcv_msg+0x1b8/0x1f8)
      [  666.177205] [<c01f9328>] (genl_rcv_msg+0x0/0x1f8) from [<c01f89a0>] (netlink_rcv_skb+0x58/0xb4)
      [  666.185949] [<c01f8948>] (netlink_rcv_skb+0x0/0xb4) from [<c01f931c>] (genl_rcv+0x20/0x2c)
      [  666.194251]  r6:c6f70780 r5:0000002c r4:c6f70780 r3:00000001
      [  666.199973] [<c01f92fc>] (genl_rcv+0x0/0x2c) from [<c01f8418>] (netlink_unicast+0x154/0x1f4)
      [  666.208449]  r4:c785ea00 r3:c01f92fc
      [  666.212057] [<c01f82c4>] (netlink_unicast+0x0/0x1f4) from [<c01f8790>] (netlink_sendmsg+0x230/0x2b0)
      [  666.221240] [<c01f8560>] (netlink_sendmsg+0x0/0x2b0) from [<c01cccf8>] (sock_sendmsg+0x90/0xa4)
      [  666.229986] [<c01ccc68>] (sock_sendmsg+0x0/0xa4) from [<c01cdcb0>] (__sys_sendmsg+0x290/0x298)
      [  666.238637]  r9:00000000 r8:c0611ec8 r6:0000002c r5:c0610000 r4:c0611f64
      [  666.245411] [<c01cda20>] (__sys_sendmsg+0x0/0x298) from [<c01cf52c>] (sys_sendmsg+0x44/0x6c)
      [  666.253897] [<c01cf4e8>] (sys_sendmsg+0x0/0x6c) from [<c00090a0>] (ret_fast_syscall+0x0/0x2c)
      [  666.262460]  r6:00000000 r5:beeff96c r4:00000005
      Signed-off-by: NJonas Gorski <jogo@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d786f67e
  8. 09 2月, 2013 3 次提交
  9. 31 1月, 2013 10 次提交
  10. 23 1月, 2013 1 次提交
  11. 10 1月, 2013 3 次提交
  12. 08 1月, 2013 8 次提交
  13. 03 1月, 2013 1 次提交
    • J
      mac80211: split TX aggregation stop action · 18b559d5
      Johannes Berg 提交于
      When TX aggregation is stopped, there are a few
      different cases:
       - connection with the peer was dropped
       - session stop was requested locally
       - session stop was requested by the peer
       - connection was dropped while a session is stopping
      
      The behaviour in these cases should be different, if
      the connection is dropped then the driver should drop
      all frames, otherwise the frames may continue to be
      transmitted, aggregated in the case of a locally
      requested session stop or unaggregated in the case of
      the peer requesting session stop.
      
      Split these different cases so that the driver can
      act accordingly; however, treat local and remote stop
      the same way and ask the driver to not send frames as
      aggregated packets any more.
      
      In the case of connection drop, the stop callback the
      driver is otherwise supposed to call is no longer
      required.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      18b559d5
  14. 07 12月, 2012 1 次提交
  15. 04 12月, 2012 1 次提交
  16. 17 11月, 2012 1 次提交
    • Y
      mwl8k: Send BASTREAM firmware commands per vif · f95275c4
      Yogesh Ashok Powar 提交于
      The firmware supports 8 macid's corresponding to 8 BSS that can be
      created in an MBSS environment. Currently, BASTREAM commands were always
      sent with macid 0. This macid is used to configure the hardware ampdu
      registers with appropriate BSS address in an MBSS environment.
      This mac address is used by the hardware for various ampdu related requirements
      e.g. source address in BAR generation, BA interpretation e.t.c.
      Using invalid macid results in this mac address not getting appropriately
      configured in the hardware which results in issues during ampdu traffic.
      
      Fix this by sending the BASTREAM commands with appropriate macid.
      Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
      Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f95275c4
  17. 15 11月, 2012 3 次提交