1. 23 4月, 2014 1 次提交
  2. 14 1月, 2014 1 次提交
    • L
      b43: Fix unload oops if firmware is not available · 0673effd
      Larry Finger 提交于
      The asyncronous firmware load uses a completion struct to hold firmware
      processing until the user-space routines are up and running. There is.
      however, a problem in that the waiter is nevered canceled during teardown.
      As a result, unloading the driver when firmware is not available causes an oops.
      
      To be able to access the completion structure at teardown, it had to be moved
      into the b43_wldev structure.
      
      This patch also fixes a typo in a comment.
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0673effd
  3. 28 3月, 2013 1 次提交
  4. 26 3月, 2013 1 次提交
  5. 07 3月, 2013 1 次提交
  6. 08 1月, 2013 1 次提交
    • L
      b43: Fix firmware loading when driver is built into the kernel · 5e20a4b5
      Larry Finger 提交于
      Recent versions of udev cause synchronous firmware loading from the
      probe routine to fail because the request to user space would time
      out. The original fix for b43 (commit 6b6fa586) moved the firmware
      load from the probe routine to a work queue, but it still used synchronous
      firmware loading. This method is OK when b43 is built as a module;
      however, it fails when the driver is compiled into the kernel.
      
      This version changes the code to load the initial firmware file
      using request_firmware_nowait(). A completion event is used to
      hold the work queue until that file is available. This driver
      reads several firmware files - the remainder can be read synchronously.
      On some test systems, the async read fails; however, a following synch
      read works, thus the async failure falls through to the sync try.
      
      Reported-and-Tested by: Felix Janda <felix.janda@posteo.de>
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org>  (V3.4+)
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5e20a4b5
  7. 07 8月, 2012 2 次提交
  8. 18 7月, 2012 1 次提交
  9. 09 6月, 2012 1 次提交
  10. 14 3月, 2012 1 次提交
  11. 25 1月, 2012 1 次提交
  12. 05 1月, 2012 1 次提交
  13. 20 12月, 2011 1 次提交
  14. 01 11月, 2011 1 次提交
  15. 28 9月, 2011 1 次提交
  16. 14 9月, 2011 1 次提交
  17. 26 8月, 2011 1 次提交
  18. 25 8月, 2011 2 次提交
  19. 23 8月, 2011 2 次提交
  20. 22 7月, 2011 1 次提交
  21. 20 7月, 2011 1 次提交
  22. 08 7月, 2011 1 次提交
  23. 18 6月, 2011 1 次提交
  24. 04 6月, 2011 2 次提交
  25. 02 6月, 2011 3 次提交
  26. 23 5月, 2011 1 次提交
  27. 20 5月, 2011 2 次提交
  28. 17 5月, 2011 1 次提交
  29. 31 3月, 2011 1 次提交
  30. 14 12月, 2010 1 次提交
    • R
      b43: rename TMS defines, drop useless condition from core reset · 42ab135f
      Rafał Miłecki 提交于
      As discussed we do not know band width at core reset time and it is not a good
      idea to reset whole just to change band. So just set unconditionally 20 MHz
      band width as default during core reset.
      
      As for defines PHY clock changed to band width in specs and it makes much more
      sens to call defines by band width which is self-explainable. Updated specs do
      not mention 0 value, but comparing to old ones you can notice lineral relation
      between PHY clock speed and band width. So it makes sense for 0x0 value to be
      10 MHz band width.
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      42ab135f
  31. 16 11月, 2010 1 次提交
  32. 07 10月, 2010 1 次提交
  33. 03 6月, 2010 1 次提交