1. 26 6月, 2010 5 次提交
    • W
      iwlwifi: add a mechanism to disable plcp error checking · 680788ac
      Wey-Yi Guy 提交于
      For some devices, especially the upcoming new devices, the plcp error
      rate is different. Before the correct error rate can be determine, also
      for the debugging purpose; add the mechanism to disable plcp error checking
      which cause radio reset happen.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      680788ac
    • W
      iwlwifi: enable DC calibration based on config parameter · 178d1596
      Wey-Yi Guy 提交于
      Different devices have different calibration requirement,
      some need DC calibration and some don't; make it a cfg parameter
      for easy management.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      178d1596
    • W
      iwlwifi: name change from signal protection flag · 4e3243f5
      Wey-Yi Guy 提交于
      This bit need to be set for both RTS/CTS or CTS-to-self protection, if
      CTS-to-self is used, then uCode will  check the RXON_FLG_SELF_CTS_EN
      status. Change the name from TX_CMD_FLG_RTS_CTS_MSK to TX_CMD_FLAG_PROT_REQUIRE_MSK
      to match the behavior of the bit setting.
      
      Also update comments to reflect which hardware uses which of the TX command
      flags.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      4e3243f5
    • W
      iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag · 062bee44
      Wey-Yi Guy 提交于
      When building tx command, always set TX_CMD_FLAG_PROT_REQUIRE_MSK
      for 5000 series and up.
      
      Without setting this bit the firmware will not examine the RTS/CTS setting
      and thus not send traffic with the appropriate protection. RTS/CTS is is
      required for HT traffic in a noisy environment where, without this setting,
      connections will stall on some hardware as documented in the patch that
      initially attempted to address this:
      
          commit 1152dcc2
          Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
          Date:   Fri Jan 15 13:42:58 2010 -0800
      
          iwlwifi: Fix throughput stall issue in HT mode for 5000
      
          Similar to 6000 and 1000 series, RTS/CTS is the recommended
          protection mechanism for 5000 series in HT mode based on the HW design.
          Using RTS/CTS will better protect the inner exchange from interference,
          especially in highly-congested environment, it also prevent uCode encounter
          TX FIFO underrun and other HT mode related performance issues.
      
      For 3945 and 4965, different flags are used for RTS/CTS or CTS-to-Self
      protection.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      062bee44
    • J
      iwlwifi: fix multicast · d1e89f37
      Johannes Berg 提交于
      commit 3474ad63
      Author: Johannes Berg <johannes.berg@intel.com>
      Date:   Thu Apr 29 04:43:05 2010 -0700
      
          iwlwifi: apply filter flags directly
      
      broke multicast. The reason, it turns out, is that
      the code previously checked if ALLMULTI _changed_,
      which the new code no longer did, and normally it
      _never_ changes. Had somebody changed it manually,
      the code prior to my patch there would have been
      broken already.
      
      The reason is that we always, unconditionally, ask
      the device to pass up all multicast frames, but the
      new code made it depend on ALLMULTI which broke it
      since now we'd pass up multicast frames depending
      on the default filter in the device, which isn't
      necessarily what we want (since we don't program it
      right now).
      
      Fix this by simply not checking allmulti as we have
      allmulti behaviour enabled already anyway.
      Reported-by: NMaxim Levitsky <maximlevitsky@gmail.com>
      Tested-by: NMaxim Levitsky <maximlevitsky@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d1e89f37
  2. 25 6月, 2010 7 次提交
  3. 24 6月, 2010 13 次提交
  4. 22 6月, 2010 10 次提交
  5. 19 6月, 2010 5 次提交
    • J
      mac80211_hwsim: fix fake_hw_scan · 8223d2f5
      Johannes Berg 提交于
      Since mac80211 will not set the max_scan parameters
      if hw scan is enabled, hwsim needs to do it so that
      cfg80211 won't reject the scan.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8223d2f5
    • S
      ath9k_htc: Update supported product list · 4e63f768
      Sujith 提交于
      This patch adds USB IDs for some more supported
      devices.
      Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4e63f768
    • J
      wireless:hostap_ap.c Fix warning: variable 'fc' set but not used · 1baf8a90
      Justin P. Mattock 提交于
      The below patch fixes a warning message when compiling with gcc 4.6.0
        CC [M]  drivers/net/wireless/hostap/hostap_ap.o
      drivers/net/wireless/hostap/hostap_ap.c: In function 'hostap_ap_tx_cb_assoc':
      drivers/net/wireless/hostap/hostap_ap.c:691:6: warning: variable 'fc' set but not used
      Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1baf8a90
    • J
      wireless:hostap_main.c warning: variable 'iface' set but not used · deda484c
      Justin P. Mattock 提交于
      The patch below fixes a warning message Im seeing with gcc 4.6.0
       CC [M]  drivers/net/wireless/hostap/hostap_main.o
      drivers/net/wireless/hostap/hostap_main.c: In function 'hostap_set_multicast_list_queue':
      drivers/net/wireless/hostap/hostap_main.c:744:27: warning: variable 'iface' set but not used
      Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      deda484c
    • B
      ath5k: initialize ah->ah_current_channel · b6855772
      Bob Copeland 提交于
      ath5k assumes ah_current_channel is always a valid pointer in
      several places, but a newly created interface may not have a
      channel.  To avoid null pointer dereferences, set it up to point
      to the first available channel until later reconfigured.
      
      This fixes the following oops:
      $ rmmod ath5k
      $ insmod ath5k
      $ iw phy0 set distance 11000
      
      BUG: unable to handle kernel NULL pointer dereference at 00000006
      IP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
      *pde = 00000000
      Oops: 0000 [#1]
      last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index
      Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90
      scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci
      8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc
      
      Pid: 1597, comm: iw Not tainted (2.6.32.14 #8)
      EIP: 0060:[<d0a1ff24>] EFLAGS: 00010296 CPU: 0
      EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
      EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080
      ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4
        DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000)
      Stack:
        d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0
      <0> cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7
      <0> 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000
      Call Trace:
        [<d0a27f0c>] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k]
        [<d09bfdc7>] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211]
        [<d08e0d28>] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211]
        [<c10f5db9>] ? nla_parse+0x59/0xc0
        [<c11ca8d9>] ? genl_rcv_msg+0x169/0x1a0
        [<c11ca770>] ? genl_rcv_msg+0x0/0x1a0
        [<c11c7e68>] ? netlink_rcv_skb+0x38/0x90
        [<c11c9649>] ? genl_rcv+0x19/0x30
        [<c11c7c03>] ? netlink_unicast+0x1b3/0x220
        [<c11c893e>] ? netlink_sendmsg+0x26e/0x290
        [<c11a409e>] ? sock_sendmsg+0xbe/0xf0
        [<c1032780>] ? autoremove_wake_function+0x0/0x50
        [<c104d846>] ? __alloc_pages_nodemask+0x106/0x530
        [<c1074933>] ? do_lookup+0x53/0x1b0
        [<c10766f9>] ? __link_path_walk+0x9b9/0x9e0
        [<c11acab0>] ? verify_iovec+0x50/0x90
        [<c11a42b1>] ? sys_sendmsg+0x1e1/0x270
        [<c1048e50>] ? find_get_page+0x10/0x50
        [<c104a96f>] ? filemap_fault+0x5f/0x370
        [<c1059159>] ? __do_fault+0x319/0x370
        [<c11a55b4>] ? sys_socketcall+0x244/0x290
        [<c101962c>] ? do_page_fault+0x1ec/0x270
        [<c1019440>] ? do_page_fault+0x0/0x270
        [<c1002ae5>] ? syscall_call+0x7/0xb
      Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24
      0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 <0f> b7
      43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2
      EIP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP
      0068:cfa09bf4
      CR2: 0000000000000006
      ---[ end trace 54f73d6b10ceb87b ]---
      
      Cc: stable@kernel.org
      Reported-by: NSteve Brown <sbrown@cortland.com>
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b6855772