1. 29 1月, 2011 1 次提交
  2. 17 11月, 2010 1 次提交
  3. 16 11月, 2010 2 次提交
  4. 08 10月, 2010 2 次提交
  5. 06 10月, 2010 1 次提交
    • 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
  6. 17 9月, 2010 1 次提交
    • J
      iwlwifi: fix sparse warning about wrong enum for band parameter · 20c956df
      John W. Linville 提交于
      drivers/net/wireless/iwlwifi/iwl-scan.c:386:27: warning: mixing different enum types
      drivers/net/wireless/iwlwifi/iwl-scan.c:386:27:     int enum nl80211_band  versus
      drivers/net/wireless/iwlwifi/iwl-scan.c:386:27:     int enum ieee80211_band
      drivers/net/wireless/iwlwifi/iwl-scan.c:435:57: warning: mixing different enum types
      drivers/net/wireless/iwlwifi/iwl-scan.c:435:57:     int enum ieee80211_band  versus
      drivers/net/wireless/iwlwifi/iwl-scan.c:435:57:     int enum nl80211_band
      drivers/net/wireless/iwlwifi/iwl-scan.c:474:53: warning: mixing different enum types
      drivers/net/wireless/iwlwifi/iwl-scan.c:474:53:     int enum ieee80211_band  versus
      drivers/net/wireless/iwlwifi/iwl-scan.c:474:53:     int enum nl80211_band
      drivers/net/wireless/iwlwifi/iwl-scan.c:588:72: warning: mixing different enum types
      drivers/net/wireless/iwlwifi/iwl-scan.c:588:72:     int enum ieee80211_band  versus
      drivers/net/wireless/iwlwifi/iwl-scan.c:588:72:     int enum nl80211_band
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      20c956df
  7. 15 9月, 2010 12 次提交
  8. 28 8月, 2010 2 次提交
  9. 27 8月, 2010 1 次提交
  10. 26 8月, 2010 2 次提交
  11. 25 8月, 2010 1 次提交
  12. 17 8月, 2010 1 次提交
  13. 07 8月, 2010 1 次提交
  14. 30 7月, 2010 1 次提交
    • S
      iwlwifi: fix scan abort · d28232b4
      Stanislaw Gruszka 提交于
      Fix possible double priv->mutex lock introduced by commit
      a69b03e9
      "iwlwifi: cancel scan watchdog in iwl_bg_abort_scan" .
      We can not call cancel_delayed_work_sync(&priv->scan_check) with
      priv->mutex locked because workqueue function iwl_bg_scan_check()
      take that lock internally.
      
      We do not need to synchronize when canceling priv->scan_check work.
      We can avoid races (sending double abort command or send no
      command at all) using STATUS_SCAN_ABORT bit. Moreover
      current iwl_bg_scan_check() code seems to be broken, as
      we should not send abort commands when currently aborting.
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      CC: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d28232b4
  15. 26 6月, 2010 1 次提交
  16. 16 6月, 2010 1 次提交
    • J
      iwlwifi: cancel scan watchdog in iwl_bg_abort_scan · a69b03e9
      John W. Linville 提交于
      Avoids this:
      
      WARNING: at net/mac80211/scan.c:312 ieee80211_scan_completed+0x5f/0x1f1
      [mac80211]()
      Hardware name: Latitude E5400
      Modules linked in: aes_x86_64 aes_generic fuse ipt_MASQUERADE iptable_nat
      nf_nat rfcomm sco bridge stp llc bnep l2cap sunrpc cpufreq_ondemand
      acpi_cpufreq freq_table xt_physdev ip6t_REJECT nf_conntrack_ipv6
      ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput arc4 ecb
      snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel iwlagn snd_hda_codec
      snd_hwdep snd_seq snd_seq_device iwlcore snd_pcm dell_wmi sdhci_pci sdhci
      iTCO_wdt tg3 dell_laptop mmc_core i2c_i801 wmi mac80211 snd_timer
      iTCO_vendor_support btusb joydev dcdbas cfg80211 bluetooth snd soundcore
      microcode rfkill snd_page_alloc firewire_ohci firewire_core crc_itu_t
      yenta_socket rsrc_nonstatic i915 drm_kms_helper drm i2c_algo_bit i2c_core video
      output [last unloaded: scsi_wait_scan]
      Pid: 979, comm: iwlagn Tainted: G        W  2.6.33.3-85.fc13.x86_64 #1
      Call Trace:
      [<ffffffff8104b558>] warn_slowpath_common+0x77/0x8f
      [<ffffffff8104b57f>] warn_slowpath_null+0xf/0x11
      [<ffffffffa01bb7d9>] ieee80211_scan_completed+0x5f/0x1f1 [mac80211]
      [<ffffffffa02a23f0>] iwl_bg_scan_completed+0xbb/0x17a [iwlcore]
      [<ffffffff81060d3d>] worker_thread+0x1a4/0x232
      [<ffffffffa02a2335>] ? iwl_bg_scan_completed+0x0/0x17a [iwlcore]
      [<ffffffff81064817>] ? autoremove_wake_function+0x0/0x34
      [<ffffffff81060b99>] ? worker_thread+0x0/0x232
      [<ffffffff810643c7>] kthread+0x7a/0x82
      [<ffffffff8100a924>] kernel_thread_helper+0x4/0x10
      [<ffffffff8106434d>] ? kthread+0x0/0x82
      [<ffffffff8100a920>] ? kernel_thread_helper+0x0/0x10
      
      Reported here:
      
      	https://bugzilla.redhat.com/show_bug.cgi?id=590436Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Reported-by: NMihai Harpau <mishu@piatafinanciara.ro>
      Cc: stable@kernel.org
      Acked-by: NReinette Chatre <reinette.chatre@intel.com>
      a69b03e9
  17. 06 6月, 2010 2 次提交
  18. 22 5月, 2010 1 次提交
    • R
      iwlwifi: fix internal scan race · 073d5eab
      Reinette Chatre 提交于
      It is possible for internal scan to race against itself if the device is
      not returning the scan results from first requests. What happens in this
      case is the cleanup done during the abort of the first internal scan also
      cleans up part of the new scan, causing it to access memory it shouldn't.
      
      Here are details:
      * First internal scan is triggered and scan command sent to device.
      * After seven seconds there is no scan results so the watchdog timer
        triggers a scan abort.
      * The scan abort succeeds and a SCAN_COMPLETE_NOTIFICATION is received for
       failed scan.
      * During processing of SCAN_COMPLETE_NOTIFICATION we clear STATUS_SCANNING
        and queue the "scan_completed" work.
      ** At this time, since the problem that caused the internal scan in first
         place is still present, a new internal scan is triggered.
      The behavior at this point is a bit different between 2.6.34 and 2.6.35
      since 2.6.35 has a lot of this synchronized. The rest of the race
      description will thus be generalized.
      ** As part of preparing for the scan "is_internal_short_scan" is set to
      true.
      * At this point the completion work for fist scan is run. As part of this
        there is some locking missing around the "is_internal_short_scan"
        variable and it is set to "false".
      ** Now the second scan runs and it considers itself a real (not internal0
         scan and thus causes problems with wrong memory being accessed.
      
      The fix is twofold.
      * Since "is_internal_short_scan" should be protected by mutex, fix this in
        scan completion work so that changes to it can be serialized.
      * Do not queue a new internal scan if one is in progress.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=15824Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      073d5eab
  19. 11 5月, 2010 2 次提交
  20. 01 5月, 2010 1 次提交
  21. 28 4月, 2010 1 次提交
  22. 17 4月, 2010 2 次提交