1. 28 10月, 2009 6 次提交
  2. 13 10月, 2009 1 次提交
  3. 08 10月, 2009 4 次提交
  4. 29 9月, 2009 1 次提交
    • R
      iwlwifi: fix 3945 ucode info retrieval after failure · b7a79404
      Reinette Chatre 提交于
      When hardware or uCode problem occurs driver captures significant
      information from device to enable debugging. The format of this information
      is different between 3945 and 4965 and later devices, yet currently the
      3945 uses the 4965 and later format. Fix this by adding a new library call
      that is initialized to the correct formatting routine based on device.
      
      This moves the iwlagn event and error log handling back to iwl-agn.c to
      make it part of iwlagn module.
      
      Also remove the 3945 sysfs file that triggers dump of event log - there is
      already a debugfs file that can do it for all drivers.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b7a79404
  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 次提交
    • G
      iwlwifi: Make injection of non-broadcast frames work again · aa065263
      Gábor Stefanik 提交于
      Commit 1ccb84d87d04df3c76cd4352fe69786d8c7cf016 by Wey-Yi Guy
      ("iwlwifi: clean up unused NL80211_IFTYPE_MONITOR for Monitor mode")
      broke injection of non-broadcast frames to unassociated stations
      (causing a SYSASSERT for all such injected frames), due to injected
      frames no longer automatically getting a broadcast station ID assigned.
      This patch restores the old behavior, fixing the aforementioned
      regression.
      
      Also, consistently check for IEEE80211_TX_CTL_INJECTED instead of
      iwl_is_monitor_mode in the TX path, as TX_CTL_INJECTED specifically
      means that a given packet is coming from a monitor interface, while
      iwl_is_monitor_mode only shows whether a monitor interface exists
      on the device.
      Signed-off-by: NGábor Stefanik <netrolller.3d@gmail.com>
      Acked-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      aa065263
  9. 20 8月, 2009 1 次提交
  10. 14 8月, 2009 4 次提交
    • 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: Traffic type and counter for debugFs · 22fdf3c9
      Wey-Yi Guy 提交于
      Break down the traffic type and counter for both Tx and Rx.
      Enhance the tx_statistics and rx_statistics debugfs function and move
      to /sys/kernel/debug/ieee80211/phy0/iwlagn/debug directory to help
      better debugging both driver and uCode related problems.
      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>
      22fdf3c9
    • W
      iwlwifi: new debugging feature for dumping data traffic · 20594eb0
      Wey-Yi Guy 提交于
      The traffic buffer will only beallocated and used if either bit 23
      (IWL_DX_TX) or bit 24 (IWL_DL_RX) of "debug" is set;
      example: "debug=0x800000" - log tx data traffic
               "debug=0x1000000" - log rx data traffic
               "debug=0x1800000" - log both tx and rx traffic
      
      The traffic log will store the beginning portion (64 bytes)  of the
      latest 256 of tx and rx packets in the round-robbin buffer for
      debugging,
      user can examine the log through debugfs file.
      
      How to display the current logged tx/rx traffic and txfifo and rxfifo
      read/write point:
      "cat traffic_log" in /sys/kernel/debug/ieee80211/phy0/iwlagn/debug
      directory
      
      By echo "0" to traffic_log file will empty the traffic log buffer and
      reset both tx and rx taffic log index to 0.
      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>
      20594eb0
    • R
      iwlwifi: re-introduce per device debugging · 3d816c77
      Reinette Chatre 提交于
      Commit "iwlwifi: make debug level more user friendly" cleaned up the
      debug level handling. In doing so it created a single global debug
      level for all devices. Some setups do consits of more that one iwlwifi
      device and in these setups there is a requirement that debug levels
      should be unique per device.
      
      We now re-introduce the per device debugging while maintaining the
      cleanup effort of the previous patch.
      
      The maintain the global debug level and now introduce a per-device debug
      level that will be used if it (the per-device debug level) is set. The
      per-device debug level can be controlled via the debug_level sysfs file
      while the global debug level is controlled by the debug module parameter.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Acked-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3d816c77
  11. 04 8月, 2009 1 次提交
    • L
      cfg80211: fix regression on beacon world roaming feature · 37184244
      Luis R. Rodriguez 提交于
      A regression was added through patch a4ed90d6:
      
      "cfg80211: respect API on orig_flags on channel for beacon hint"
      
      We did indeed respect _orig flags but the intention was not clearly
      stated in the commit log. This patch fixes firmware issues picked
      up by iwlwifi when we lift passive scan of beaconing restrictions
      on channels its EEPROM has been configured to always enable.
      
      By doing so though we also disallowed beacon hints on devices
      registering their wiphy with custom world regulatory domains
      enabled, this happens to be currently ath5k, ath9k and ar9170.
      The passive scan and beacon restrictions on those devices would
      never be lifted even if we did find a beacon and the hardware did
      support such enhancements when world roaming.
      
      Since Johannes indicates iwlwifi firmware cannot be changed to
      allow beacon hinting we set up a flag now to specifically allow
      drivers to disable beacon hints for devices which cannot use them.
      
      We enable the flag on iwlwifi to disable beacon hints and by default
      enable it for all other drivers. It should be noted beacon hints lift
      passive scan flags and beacon restrictions when we receive a beacon from
      an AP on any 5 GHz non-DFS channels, and channels 12-14 on the 2.4 GHz
      band. We don't bother with channels 1-11 as those channels are allowed
      world wide.
      
      This should fix world roaming for ath5k, ath9k and ar9170, thereby
      improving scan time when we receive the first beacon from any AP,
      and also enabling beaconing operation (AP/IBSS/Mesh) on cards which
      would otherwise not be allowed to do so. Drivers not using custom
      regulatory stuff (wiphy_apply_custom_regulatory()) were not affected
      by this as the orig_flags for the channels would have been cleared
      upon wiphy registration.
      
      I tested this with a world roaming ath5k card.
      
      Cc: Jouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      37184244
  12. 28 7月, 2009 2 次提交
  13. 25 7月, 2009 5 次提交
    • R
      iwlwifi: inform user about rfkill state changes · 4c423a2b
      Reinette Chatre 提交于
      rfkill state changes are mostly available through debug messages.
      These are significant enough to always make user aware of so
      we turn them into warnings.
      
      Also insert a missing newline in some rfkill related debug message.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4c423a2b
    • R
      iwlwifi: clarify hardware error message · 58dba728
      Reinette Chatre 提交于
      When a hardware error is detected we need to be clear about that
      and not create impression that the microcode is able to deal
      with it.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      58dba728
    • 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
    • J
      iwlwifi: Handle new firmware file with ucode build number in header · cc0f555d
      Jay Sternberg 提交于
      Adding new API version to account for change to ucode file format.  New
      header includes the build number of the ucode.  This build number is the
      SVN revision thus allowing for exact correlation to the code that
      generated it.
      
      The header adds the build number so that older ucode images can also be
      enhanced to include the build in the future.
      
      some cleanup in iwl_read_ucode needed to ensure old header not used and
      reduce unnecessary references through pointer with the data is already
      in heap variable.
      Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cc0f555d
    • R
      iwl3945: cleanup number of queues settings · 5905a1aa
      Reinette Chatre 提交于
      * Rename maximum number of queue (TFD_QUEUE_MAX) to IWL39_NUM_QUEUES to
        be consistent with rest of iwlwifi.
      * Remove unused defines.
      * Fix loops that iterate over number of TX queues to stop when maximum is reached
        (currently it is maximum + 1).
      * Remove queues_num module parameter as it is not used.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5905a1aa
  14. 22 7月, 2009 1 次提交
  15. 11 7月, 2009 2 次提交
  16. 16 6月, 2009 1 次提交
  17. 11 6月, 2009 1 次提交
  18. 04 6月, 2009 2 次提交
  19. 23 5月, 2009 3 次提交