1. 19 11月, 2009 1 次提交
  2. 12 11月, 2009 2 次提交
  3. 28 10月, 2009 4 次提交
    • Z
      iwlwifi: fix use after free bug for paged rx · 29b1b268
      Zhu Yi 提交于
      In the paged rx patch (4854fde2), I introduced a bug that could possibly
      touch an already freed page. It is fixed by avoiding the access in this
      patch. I've also added some comments so that other people touching the
      code won't make the same mistake. In the future, if we cannot avoid
      access the page after being handled to the upper layer, we can use
      get_page/put_page to handle it. For now, it's just not necessary.
      
      It also fixed a debug message print bug reported by Stanislaw Gruszka
      <sgruszka@redhat.com>.
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      29b1b268
    • W
      iwlwifi: separate led function from statistic notification · 1ed2a3d2
      Wey-Yi Guy 提交于
      Detach led background task from statistic notification routine. if led
      blinking is required; the blink rate is based on the traffic condition.
      It do not relate to statistics notification. In addition to that, there is
      not a requirement for statistics notification has to occur all the time.
      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>
      1ed2a3d2
    • Z
      iwlwifi: use paged Rx · 2f301227
      Zhu Yi 提交于
      This switches the iwlwifi driver to use paged skb from linear skb for Rx
      buffer. So that it relieves some Rx buffer allocation pressure for the
      memory subsystem. Currently iwlwifi (4K for 3945) requests 8K bytes for
      Rx buffer. Due to the trailing skb_shared_info in the skb->data,
      alloc_skb() will do the next order allocation, which is 16K bytes. This
      is suboptimal and more likely to fail when the system is under memory
      usage pressure. Switching to paged Rx skb lets us allocate the RXB
      directly by alloc_pages(), so that only order 1 allocation is required.
      
      It also adjusts the area spin_lock (with IRQ disabled) protected in the
      tasklet because tasklet guarentees to run only on one CPU and the new
      unprotected code can be preempted by the IRQ handler. This saves us from
      spawning another workqueue to make skb_linearize/__pskb_pull_tail happy
      (which cannot be called in hard irq context).
      
      Finally, mac80211 doesn't support paged Rx yet. So we linearize the skb
      for all the management frames and software decryption or defragmentation
      required data frames before handed to mac80211. For all the other frames,
      we __pskb_pull_tail 64 bytes in the linear area of the skb for mac80211
      to handle them properly.
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2f301227
    • W
      iwlwifi: showing accumulative ucode statistics counters · 92a35bda
      Wey-Yi Guy 提交于
      Adding accumulative statistics counters in iwlwifi driver.
      Statistics counters are reported by uCode every beacon interval; but can
      be reset by uCode when needed. The accumulative statistics counters is
      maintained by driver to keep track of the history of all the counters.
      
      Update the ucode stats files in debugfs to display both latest and
      accumulative counters.
      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>
      92a35bda
  4. 08 10月, 2009 1 次提交
  5. 23 9月, 2009 2 次提交
    • R
      iwlwifi: reduce noise when skb allocation fails · f82a924c
      Reinette Chatre 提交于
      Replenishment of receive buffers is done in the tasklet handling
      received frames as well as in a workqueue. When we are in the tasklet
      we cannot sleep and thus attempt atomic skb allocations. It is generally
      not a big problem if this fails since iwl_rx_allocate is always followed
      by a call to iwl_rx_queue_restock which will queue the work to replenish
      the buffers at a time when sleeping is allowed.
      
      We thus add the __GFP_NOWARN to the skb allocation in iwl_rx_allocate to
      reduce the noise if such an allocation fails while we still have enough
      buffers. We do maintain the warning and the error message when we are low
      on buffers to communicate to the user that there is a potential problem with
      memory availability on system
      
      This addresses issue reported upstream in thread "iwlagn: order 2 page
      allocation failures" in
      http://thread.gmane.org/gmane.linux.kernel.wireless.general/39187Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Acked-by: NMel Gorman <mel@csn.ul.ie>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f82a924c
    • R
      iwlwifi: fix potential rx buffer loss · de0bd508
      Reinette Chatre 提交于
      RX handling maintains a few lists that keep track of the RX buffers.
      Buffers move from one list to the other as they are used, replenished, and
      again made available for usage. In one such instance, when a buffer is used
      it enters the "rx_used" list. When buffers are replenished an skb is
      attached to the buffer and it is moved to the "rx_free" list. The problem
      here is that the buffer is first removed from the "rx_used" list _before_ the
      skb is allocated. Thus, if the skb allocation fails this buffer remains
      removed from the "rx_used" list and is thus lost for future usage.
      
      Fix this by first allocating the skb before trying to attach it to a list.
      We add an additional check to not do this unnecessarily.
      Reported-by: NRick Farrington <rickdic@hotmail.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      de0bd508
  6. 15 9月, 2009 1 次提交
    • R
      iwlwifi: fix potential rx buffer loss · 0aae511c
      Reinette Chatre 提交于
      RX handling maintains a few lists that keep track of the RX buffers.
      Buffers move from one list to the other as they are used, replenished, and
      again made available for usage. In one such instance, when a buffer is used
      it enters the "rx_used" list. When buffers are replenished an skb is
      attached to the buffer and it is moved to the "rx_free" list. The problem
      here is that the buffer is first removed from the "rx_used" list _before_ the
      skb is allocated. Thus, if the skb allocation fails this buffer remains
      removed from the "rx_used" list and is thus lost for future usage.
      
      Fix this by first allocating the skb before trying to attach it to a list.
      We add an additional check to not do this unnecessarily.
      Reported-by: NRick Farrington <rickdic@hotmail.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0aae511c
  7. 01 9月, 2009 1 次提交
  8. 29 8月, 2009 1 次提交
  9. 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
  10. 14 8月, 2009 4 次提交
  11. 05 8月, 2009 1 次提交
  12. 25 7月, 2009 2 次提交
    • R
      iwlwifi: make debug level more user friendly · a562a9dd
      Reinette Chatre 提交于
      * Deprecate the "debug50" module parameter used to obtain
        5000 series and up debugging. Replace it with "debug" module
        parameter to match with original driver and be consistent
        between them. The "debug50" module parameter can still be used,
        except that the module parameter is not writable in keeping
        with its previous state. We currently just mark it as "deprecated"
        and do not have it in the feature-removal-schedule. Some more
        cleanup of module parameters needs to be done and can then be
        entered together.
      
      * Only make "debug" module parameters visible if the driver
        is compiled with CONFIG_IWLWIFI_DEBUG. This will eliminate
        a lot of confusion where users think they have set debug flags
        but yet cannot see any debug output.
      
      * Make module parameters writable. This eliminates the need for the
        "debug_level" sysfs file, which can now also be deprecated and
        added to feature-removal-schedule. This file is in significant
        use though with many iwlwifi documents and text referring users
        to it. We can thus not take its removal lightly and keep it around.
      
      With iwlcore shared between iwlagn and iwl3945 we really do not need
      debug module parameters for each but can instead have one debug
      module parameter for the iwlcore module. The same issue is here as
      with the sysfs file - a lot of iwlwifi documentation and text (like
      bug reports) rely on iwlagn and iwl3945 having this module parameter,
      so changing this to a module parameter of iwlcore will have significant
      impact and we do not do this for that reason.
      
      One consequence of this patch is that if a user is running a system
      with both 3945 and later hardware then the setting of the one module
      parameter will affect the value of the other. The likelihood of this
      seems low - and even if this setup is present it does not seem like an
      issue for both modules to run with the same debug level.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a562a9dd
    • W
      iwlwifi: fix rx signal quality reporting in dmesg · 244294e8
      Wey-Yi Guy 提交于
      Fix quality incorrectly reported as signal strength value.
      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>
      244294e8
  13. 11 7月, 2009 2 次提交
  14. 23 5月, 2009 4 次提交
  15. 23 4月, 2009 1 次提交
  16. 10 2月, 2009 2 次提交
  17. 30 1月, 2009 5 次提交
  18. 20 12月, 2008 1 次提交
    • Z
      iwlwifi: use GFP_KERNEL to allocate Rx SKB memory · f1bc4ac6
      Zhu Yi 提交于
      Previously we allocate Rx SKB with GFP_ATOMIC flag. This is because we need
      to hold a spinlock to protect the two rx_used and rx_free lists operation
      in the rxq.
      
      	spin_lock();
      	...
      	element = rxq->rx_used.next;
      	element->skb = alloc_skb(..., GFP_ATOMIC);
      	list_del(element);
      	list_add_tail(&element->list, &rxq->rx_free);
      	...
      	spin_unlock();
      
      After spliting the rx_used delete and rx_free insert into two operations,
      we don't require the skb allocation in an atomic context any more (the
      function itself is scheduled in a workqueue).
      
      	spin_lock();
      	...
      	element = rxq->rx_used.next;
      	list_del(element);
      	...
      	spin_unlock();
      	...
      	element->skb = alloc_skb(..., GFP_KERNEL);
      	...
      	spin_lock()
      	...
      	list_add_tail(&element->list, &rxq->rx_free);
      	...
      	spin_unlock();
      
      This patch should fix the "iwlagn: Can not allocate SKB buffers" warning
      we see recently.
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Acked-by: NTomas Winkler <tomas.winkler@intel.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f1bc4ac6
  19. 13 12月, 2008 3 次提交