1. 28 10月, 2009 4 次提交
  2. 08 10月, 2009 3 次提交
    • J
      iwlwifi: LED cleanup · e932a609
      Johannes Berg 提交于
      The iwlwifi drivers have LED blinking requirements that
      mac80211 cannot fulfill due to the use of just a single
      LED instead of different ones for TX, RX, radio etc.
      Instead, the single LED blinks according to transfers
      and is solid on the rest of the time. As such, having
      LED class devices registered that mac80211 triggers are
      connected to is pointless as we don't use the triggers
      anyway.
      
      Remove all the useless code and add hooks into the
      driver itself. At the same time, make the LED code
      abstracted so the core code that determines blink rate
      etc. can be shared between 3945 and agn in iwlcore.
      
      At the same time, the fact that we removed the use of
      the mac80211 LED triggers means we can also remove the
      IWLWIFI_LEDS Kconfig symbol since the LED support is
      now self-contained.
      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>
      e932a609
    • W
      iwlwifi: reliable entering of critical temperature state · 7812b167
      Wey-Yi Guy 提交于
      When uCode detects critical temperature it should send "card state
      notification" interrupt to driver and then shut itself down to prevent
      overheating. There is a race condition where uCode shuts down before it
      can deliver the interrupt to driver.
      Additional method provided here for driver to enter CT_KILL state based
      on temperature reading.
      
      How it works:
      Method 1:
      If driver receive "card state notification" interrupt from uCode; it
      enters "CT_KILL" state immediately
      
      Method 2:
      If the last temperature report by Card reach Critical temperature,
      driver will send "statistic notification" request to uCode to verify the
      temperature reading, if driver can not get reply from uCode within
      300ms, driver will enter CT_KILL state automatically.
      
      Method 3:
      If the last temperature report by Card did not reach Critical
      temperature, but uCode already shut down due to critical temperature.
      All the host commands send to uCode will not get process by uCode;
      when command queue reach the limit, driver will check the last reported
      temperature reading, if it is within pre-defined margin, enter "CT_KILL"
      state immediately. In this case, when uCode ready to exit from "CT_KILL" state,
      driver need to restart the adapter in order to reset all the queues and
      resume normal operation.
      
      One additional issue being address here, when system is in CT_KILL
      state, both tx and rx already stopped, but driver still can send host
      command to uCode, it will flood the command queue since card was not
      responding; adding STATUS_CT_KILL flag to reject enqueue host commands
      to uCode if it is in CT_KILL state, when uCode is ready to come out of
      CT_KILL, driver will clear  the STATUS_CT_KILL bit and allow enqueue the host
      commands to uCode to recover from CT_KILL state.
      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>
      7812b167
    • W
      iwlwifi: show NVM version in debugfs · e307ddce
      Wey-Yi Guy 提交于
      Show version number along with dumping NVM data, the version information
      being removed from sysfs, add it back to debugfs to help debugging.
      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>
      e307ddce
  3. 29 9月, 2009 2 次提交
    • 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
    • R
      iwlwifi: fix debugfs buffer handling · 2fac9717
      Reinette Chatre 提交于
      We keep track of where to write into a buffer by keeping a count of how
      much has been written so far. When writing to the buffer we thus take the
      buffer pointer and adding the count of what has been written so far.
      Keeping track of what has been written so far is done by incrementing
      this number every time something is written to the buffer with how much has
      been written at that time.
      
      Currently this number is incremented incorrectly when using the
      "hex_dump_to_buffer" call to add data to the buffer. Fix this by only
      adding what has been added to the buffer in that call instead of what has
      been added since beginning of buffer.
      
      Issue was discovered and discussed during testing of
      https://bugzilla.redhat.com/show_bug.cgi?id=464598 .
      
      When a user views any of these files they will see something like:
      
      [  179.355202] ------------[ cut here ]------------
      [  179.355209] WARNING: at ../lib/vsprintf.c:989 vsnprintf+0x5ec/0x5f0()
      [  179.355212] Hardware name: VGN-Z540N
      [  179.355213] Modules linked in: i915 drm i2c_algo_bit i2c_core ipv6 acpi_cpufreq cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative cpufreq_stats freq_table container sbs sbshc arc4 ecb iwlagn iwlcore joydev led_class mac80211 af_packet pcmcia psmouse sony_laptop cfg80211 iTCO_wdt iTCO_vendor_support pcspkr serio_raw rfkill intel_agp video output tpm_infineon tpm tpm_bios button battery yenta_socket rsrc_nonstatic pcmcia_core processor ac evdev ext3 jbd mbcache sr_mod sg cdrom sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore thermal fan thermal_sys
      [  179.355262] Pid: 5449, comm: cat Not tainted 2.6.31-wl-54419-ge881071 #62
      [  179.355264] Call Trace:
      [  179.355267]  [<ffffffff811ad14c>] ? vsnprintf+0x5ec/0x5f0
      [  179.355271]  [<ffffffff81041348>] warn_slowpath_common+0x78/0xd0
      [  179.355275]  [<ffffffff810413af>] warn_slowpath_null+0xf/0x20
      [  179.355277]  [<ffffffff811ad14c>] vsnprintf+0x5ec/0x5f0
      [  179.355280]  [<ffffffff811ad23d>] ? scnprintf+0x5d/0x80
      [  179.355283]  [<ffffffff811ad23d>] scnprintf+0x5d/0x80
      [  179.355286]  [<ffffffff811aed29>] ? hex_dump_to_buffer+0x189/0x340
      [  179.355290]  [<ffffffff810e91d7>] ? __kmalloc+0x207/0x260
      [  179.355303]  [<ffffffffa02a02f8>] iwl_dbgfs_nvm_read+0xe8/0x220 [iwlcore]
      [  179.355306]  [<ffffffff811a9b62>] ? __up_read+0x92/0xb0
      [  179.355310]  [<ffffffff810f0988>] vfs_read+0xc8/0x1a0
      [  179.355313]  [<ffffffff810f0b50>] sys_read+0x50/0x90
      [  179.355316]  [<ffffffff8100bd6b>] system_call_fastpath+0x16/0x1b
      [  179.355319] ---[ end trace 2383d0d5e0752ca0 ]---
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2fac9717
  4. 29 8月, 2009 1 次提交
  5. 14 8月, 2009 7 次提交
  6. 04 8月, 2009 1 次提交
    • J
      drivers/net/wireless/iwlwifi: introduce missing kfree · c37457e6
      Julia Lawall 提交于
      Move orthogonal error handling code up before a kzalloc, so that it
      doesn't have to free the allocated data.
      
      The semantic match that finds the problem is as follows:
      (http://www.emn.fr/x-info/coccinelle/)
      
      // <smpl>
      @r exists@
      local idexpression x;
      statement S;
      expression E;
      identifier f,f1,l;
      position p1,p2;
      expression *ptr != NULL;
      @@
      
      x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
      ...
      if (x == NULL) S
      <... when != x
           when != if (...) { <+...x...+> }
      (
      x->f1 = E
      |
       (x->f1 == NULL || ...)
      |
       f(...,x->f1,...)
      )
      ...>
      (
       return \(0\|<+...x...+>\|ptr\);
      |
       return@p2 ...;
      )
      
      @script:python@
      p1 << r.p1;
      p2 << r.p2;
      @@
      
      print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Acked-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c37457e6
  7. 30 7月, 2009 1 次提交
  8. 28 7月, 2009 1 次提交
  9. 25 7月, 2009 3 次提交
  10. 11 7月, 2009 1 次提交
  11. 11 6月, 2009 1 次提交
  12. 23 5月, 2009 3 次提交
  13. 23 4月, 2009 3 次提交
  14. 28 3月, 2009 1 次提交
  15. 30 1月, 2009 4 次提交
  16. 13 12月, 2008 1 次提交
  17. 05 12月, 2008 1 次提交
  18. 01 11月, 2008 1 次提交
  19. 28 10月, 2008 1 次提交