1. 19 11月, 2009 4 次提交
  2. 12 11月, 2009 1 次提交
  3. 03 11月, 2009 2 次提交
  4. 28 10月, 2009 6 次提交
  5. 08 10月, 2009 2 次提交
  6. 29 8月, 2009 2 次提交
  7. 20 8月, 2009 2 次提交
    • D
      iwlwifi: fix erroneous use of iwl_rx_packet.len as a length · 396887a2
      Daniel C Halperin 提交于
      The field called 'len' in struct iwl_rx_packet is in fact not just a length
      field but also includes some flags from the flow handler.  In several places
      throughout the driver, this causes incorrect values to be interpreted as
      lengths when the field is improperly masked.
      
      In most situations the improper use is for debugging output, and simply results
      in an erroneous message, such as:
      
      [551933.070224] ieee80211 phy0: I iwl_rx_statistics Statistics notification received (480 vs -1367342620).
      
      which should read '(480 vs 484)'.
      
      In at least one case this could case bad things to happen:
      
      void iwl_rx_pm_debug_statistics_notif(struct iwl_priv *priv,
                                            struct iwl_rx_mem_buffer *rxb)
      {
              struct iwl_rx_packet *pkt = (struct iwl_rx_packet *)rxb->skb->data;
              IWL_DEBUG_RADIO(priv, "Dumping %d bytes of unhandled "
                              "notification for %s:\n",
                              le32_to_cpu(pkt->len), get_cmd_string(pkt->hdr.cmd));
              iwl_print_hex_dump(priv, IWL_DL_RADIO, pkt->u.raw, le32_to_cpu(pkt->len)
      );
      }
      EXPORT_SYMBOL(iwl_rx_pm_debug_statistics_notif);
      
      Given the rampant misuse of this field without proper masking throughout the
      driver (every use but one), this patch renames the field from 'len' to
      'len_n_flags' to reduce confusion.  It also adds the proper masking when
      this field is used as a length value.
      Signed-off-by: NDaniel C Halperin <daniel.c.halperin@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      396887a2
    • D
      iwlwifi: refactor packet reception code · 9f30e04e
      Daniel C Halperin 提交于
      This patch fixes a number of issues in iwl_rx_reply_rx and
      iwl_pass_packet_to_mac80211.  These issues stem from the complexities of
      managing two different types of packet commands for different hardware.
      
      - Unify code handling rx_phy_res in SKB or cached to eliminate redundancy and
      remove potential NULL pointer accesses
      - Replace magic number with proper constant
      - Optimize functions by moving early exit conditions before computation
      - Comment code and improve some variable names
      - Remove redundant computation in iwl_pass_packet_to_mac80211 by passing in the
      correct, already-computed arguments.
      Signed-off-by: NDaniel C Halperin <daniel.c.halperin@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9f30e04e
  8. 14 8月, 2009 2 次提交
    • J
      iwlwifi: automatically adjust sleep level · e312c24c
      Johannes Berg 提交于
      Depending on required latency requested by pm_qos (via mac80211)
      we can automatically adjust the sleep state. Also, mac80211 has
      a user-visible dynamic sleep feature where we are supposed to
      stay awake after sending/receiving frames to better receive
      response frames to our packets, this can be integrated into the
      sleep command.
      
      Currently, and this patch doesn't change that yet, we default
      to using sleep level 1 if PS is enabled. With a module parameter
      to iwlcore, automatic adjustment to changing network latency
      requirements can be enabled -- this isn't yet the default due
      to requiring more testing.
      
      The goal is to enable automatic adjustment and then go into the
      deepest possible sleep state possible depending on the networking
      latency requirements.
      
      This patch does, however, enable IEEE80211_HW_SUPPORTS_DYNAMIC_PS
      to avoid the double-timer (one in software and one in the device)
      when transmitting -- the exact timeout may be ignored but that is
      not of big concern.
      
      Note also that we keep the hard-coded power indices around for
      thermal throttling -- the specification of that calls for using
      the specified power levels. Those can also be selected in debugfs
      to allow easier testing of such parameters.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e312c24c
    • W
      iwlwifi: name changed from "fat" to "ht40" · 7aafef1c
      Wey-Yi Guy 提交于
      Rename "fat" to "ht40"
      The term "fat channel" is deprecated in favor of "HT40"
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7aafef1c
  9. 28 7月, 2009 1 次提交
  10. 11 7月, 2009 2 次提交
  11. 04 6月, 2009 2 次提交
  12. 23 5月, 2009 1 次提交
  13. 23 4月, 2009 2 次提交
  14. 10 2月, 2009 2 次提交
  15. 30 1月, 2009 7 次提交
  16. 13 1月, 2009 1 次提交
  17. 20 12月, 2008 1 次提交