1. 08 10月, 2010 8 次提交
  2. 07 10月, 2010 19 次提交
  3. 06 10月, 2010 13 次提交
    • W
      iwlagn: define 130 series of WiFi/BT combo devices · 58a39090
      Wey-Yi Guy 提交于
      add new structures and defines need to identify 130 devices.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      58a39090
    • W
      iwlagn: rename iwl5000_tx_resp · 898dade1
      Wey-Yi Guy 提交于
      iwl5000_tx_resp really should be iwlagn_tx_resp, rename it.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      898dade1
    • W
      iwlwifi: remove uncorrect comments · a8029bb7
      Wey-Yi Guy 提交于
      some structure belong to _agn devices, not just 5000. Fix it.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      a8029bb7
    • W
      iwlagn: rename iwl5000_tx_power_dbm_cmd · ab63c68a
      Wey-Yi Guy 提交于
      iwl5000_tx_power_dbm_cmd really should be iwlagn_tx_power_dbm_cmd,
      so rename it.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      ab63c68a
    • W
      iwlagn: reduce redundant parameter definitions · 7cb1b088
      Wey-Yi Guy 提交于
      move paramater definitions to a device paramater structure only
      leaving the device name, which antennas are used and what firmware
      file to use in the iwl_cfg structure.  this will not completely
      remove the redundancies but greatly reduce them for devices that
      only vary by name or antennas.  the parameters that are more
      likely to change within a given device family are left in iwl_cfg.
      also separate bt param structure added to help reduce more.
      Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      7cb1b088
    • W
      iwlwifi: schedule to deprecate software scan support · 72645eff
      Wey-Yi Guy 提交于
      Hardware scan is the prefer method for all iwlwifi devices;
      especially for dual-mode functions. Schedule to deprecate the
      software scan support in kernel 2.6.40
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      72645eff
    • G
      ath9k: get correct tx gain type in ath9k_hw_4k_get_eeprom · 970bf9d4
      Gabor Juhos 提交于
      The base_eep_header_4k structure contains information that the
      device supports high power tx gain table or not. However the
      ath9k_hw_4k_get_eeprom function does not return that value when
      it is called with EEP_TXGAIN_TYPE. This leads to that the tx gain
      initialization will use the init values from the original tx gain
      table even if the device inidicates that the high power table
      should be used.
      
      Changes-licensed-under: ISC
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: NShu Hwa Shen <shensh@zcomm.com.cn>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      970bf9d4
    • B
      ath5k: Don't wake internal queues · 4198a8d0
      Bruno Randolf 提交于
      We should only wake up queues which mac80211 knows about (queues 0-3). We have
      another internal queue ("CAB", queue number 6) which we use for power-saved
      frames. When transmitted frames are processed from this queue, we have to make
      sure we don't bother mac80211 with waking a queue it doesn't know about.
      
      this fixes:
      
      WARNING: at /home/br1/ath/wireless-testing/net/mac80211/util.c:275
        __ieee80211_wake_queue+0xd6/0xe0 [mac80211]()
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4198a8d0
    • D
      ipw2200: check for allocation failures · 2ee4e27c
      Dan Carpenter 提交于
      If kzalloc() fails then return should return with -ENOMEM.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2ee4e27c
    • H
      rt2x00: Work around hw aggregation oddity in rt2800 · b34793ee
      Helmut Schaa 提交于
      If a frame is not meant to be sent as AMPDU or part of it the hw might
      still decide to aggregate this frame if a previous frame started an
      AMPDU. However, this will limit the usefulness of the reported tx rate
      since the reported rate will be the one specified in the TXWI of the
      first frame and thus it is not possible to reliably caculate the
      number of retrys by substracting the reported tx rate from the tx rate
      in the TXWI.
      
      To fix this issue, only report the successful rate for frames that were
      not meant to be aggregated but ended up in an aggregate.
      
      Example:
      Frame A (MCS7, AMPDU=1) B (MCS7, AMPDU=1) C (MCS12, AMDPU=0, PROBE_RATE)
      
      Although frame C shoudn't be aggregated the hw might sill put it
      into an AMPDU together with A and B. If the transmission succeeds the tx
      status will contain MCS7 for all three frames. In that case we should
      only report MCS7 as success rate and avoid reporting MCS12-MCS8 as
      failed tx attempts as this will affect the future rate control
      decisions.
      
      This oddity might strike us in other scenarious as well but the most
      common "wrong" report happened for frames used to probe a different tx
      rate.
      
      This improves the rate control decisions notable.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b34793ee
    • H
      rt2x00: Improve cooperation between rt2800pci and minstrel · 01e946f2
      Helmut Schaa 提交于
      In order to lower the impact of probe rates don't send a frame as AMPDU
      if the rate control algorithm sets IEEE80211_TX_CTL_RATE_CTRL_PROBE.
      Otherwise a whole aggregate would be send with a probe rate which might
      lead to numerous retries.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      01e946f2
    • H
      rt2x00: Fix oops caused by error path in rt2x00lib_start · 1f0280cb
      Helmut Schaa 提交于
      When rt2x00lib_enable_radio fails to enable the radio, rt2x00lib_start
      will call rt2x00queue_uninitialize to uninitialize the queues. Since,
      the queues are not initialized here but already in rt2x00lib_initialize
      we shouldn't uninitialize the queues here. Otherwise, a consecutive call
      to rt2x00lib_start will oops (see below) because it assumes the queues
      are already initialized.
      
      BUG: unable to handle kernel NULL pointer dereference at 00000010
      IP: [<f8d2d901>] :rt2800pci:rt2800pci_clear_entry+0x1/0x40
      *pde = 00000000
      Oops: 0000 [#1] SMP
      Modules linked in: ... rt2800pci ...
      
      Pid: 5995, comm: hostapd Not tainted (2.6.27.8 #1)
      EIP: 0060:[<f8d2d901>] EFLAGS: 00210246 CPU: 3
      EIP is at rt2800pci_clear_entry+0x1/0x40 [rt2800pci]
      EAX: 00000000 EBX: f698863c ECX: 00200296 EDX: f8d2dee0
      ESI: f6988600 EDI: f5b6f000 EBP: 00000000 ESP: f6d75e4c
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process hostapd (pid: 5995, ti=f6d74000 task=f6ce2300 task.ti=f6d74000)
      Stack: f698863c fa00eaec 00000000 f5b6f000 00000000 f7b67000 f5b6e280 fa00c629
            f5b6f000 00000000 fa00ca3d f7b67480 00000001 fa177d4c 01b6e890 f7b67000
            00000000 f7b67000 00000001 00001003 00001002 c066c366 f7b67000 c0668ad0
      Call Trace:
       [<fa00eaec>] rt2x00queue_init_queues+0x5c/0x90 [rt2x00lib]
       [<fa00c629>] rt2x00lib_enable_radio+0x29/0xa0 [rt2x00lib]
       [<fa00ca3d>] rt2x00lib_start+0x5d/0xd0 [rt2x00lib]
       [<fa177d4c>] ieee80211_do_open+0x21c/0x510 [mac80211]
       [<c066c366>] dev_open+0x56/0xb0
       [<c0668ad0>] dev_set_rx_mode+0x20/0x40
       [<c066a67f>] dev_change_flags+0x7f/0x190
       [<c06b1495>] devinet_ioctl+0x515/0x690
       [<c0668d24>] __dev_get_by_name+0x74/0x90
       [<c065d3f0>] sock_ioctl+0xd0/0x240
       [<c065d320>] sock_ioctl+0x0/0x240
       [<c018179b>] vfs_ioctl+0x2b/0x90
       [<c0181a5b>] do_vfs_ioctl+0x25b/0x2a0
       [<c0181af6>] sys_ioctl+0x56/0x70
       [<c0103262>] syscall_call+0x7/0xb
       [<c0700000>] add_card+0xad0/0xba0
       =======================
      Code: 83 78 08 0e 74 14 8b 02 8b 48 04 85 c9 0f 99 c0 0f b6 c0 c3 8d b6
            00 00 00 00 8b 02 8b 40 04 85 c0 0f 99 c0 0f b6 c0 c3 66 90 53 <8b>
            48 10 8b 58 08 8b 40 04 83 78 08 0e 74 15 8b 11 83 c2 04 8b
      EIP: [<f8d2d901>] rt2800pci_clear_entry+0x1/0x40 [rt2800pci] SS:ESP 0068:f6d75e4c
      ---[ end trace cff9a5c094bb8837 ]---
      Reported-by: NJoshua Smith <jesmith@kaon.com>
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1f0280cb
    • H
      rt2x00: Update comment about the AMPDU flag in the TXWI · 74ee3802
      Helmut Schaa 提交于
      During testing with AMPDUs it turned out that the rt2800 hw will aggregate
      consecutive frames with the same RA and TID when the first frame in a
      possible aggregate has set AMPDU=1 in the TXWI. If a following frame has
      set AMPDU=0 in its TXWI it might sill end up in the aggregate of the
      previous frame. Update the comment accordingly.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      74ee3802