An error occurred fetching the project authors.
  1. 01 Jul, 2014 1 commit
  2. 25 Jun, 2014 1 commit
  3. 20 Jun, 2014 2 commits
  4. 19 Jun, 2014 5 commits
  5. 29 May, 2014 2 commits
  6. 22 May, 2014 2 commits
  7. 20 May, 2014 2 commits
  8. 19 May, 2014 4 commits
  9. 13 May, 2014 1 commit
  10. 30 Apr, 2014 2 commits
  11. 22 Apr, 2014 2 commits
  12. 03 Mar, 2014 1 commit
  13. 13 Jan, 2014 2 commits
    • Larry Finger's avatar
      b43: Fix unload oops if firmware is not available · 0673effd
      Larry Finger authored
      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: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0673effd
    • Larry Finger's avatar
      b43: Fix lockdep splat · 09164043
      Larry Finger authored
      In https://bugzilla.kernel.org/show_bug.cgi?id=67561, a locking dependency is reported
      when b43 is used with hostapd, and rfkill is used to kill the radio output.
      
      The lockdep splat (in part) is as follows:
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.12.0 #1 Not tainted
      -------------------------------------------------------
      rfkill/10040 is trying to acquire lock:
       (rtnl_mutex){+.+.+.}, at: [<ffffffff8146f282>] rtnl_lock+0x12/0x20
      
      but task is already holding lock:
       (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa04832ca>] rfkill_fop_write+0x6a/0x170 [rfkill]
      
      --snip--
      
      Chain exists of:
        rtnl_mutex --> misc_mtx --> rfkill_global_mutex
      
      The fix is to move the initialization of the hardware random number generator
      outside the code range covered by the rtnl_mutex.
      Reported-by: default avataryury <urykhy@gmail.com>
      Tested-by: default avataryury <urykhy@gmail.com>
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      09164043
  14. 26 Aug, 2013 1 commit
  15. 27 Jun, 2013 1 commit
  16. 12 Jun, 2013 1 commit
  17. 08 May, 2013 1 commit
  18. 27 Mar, 2013 1 commit
  19. 25 Mar, 2013 2 commits
  20. 06 Mar, 2013 1 commit
  21. 25 Feb, 2013 1 commit
    • Larry Finger's avatar
      b43: Fix lockdep splat on module unload · 63a02ce1
      Larry Finger authored
      On unload, b43 produces a lockdep warning that can be summarized in the
      following way:
      
       ======================================================
       [ INFO: possible circular locking dependency detected ]
       3.8.0-wl+ #117 Not tainted
       -------------------------------------------------------
       modprobe/5557 is trying to acquire lock:
        ((&wl->firmware_load)){+.+.+.}, at: [<ffffffff81062160>] flush_work+0x0/0x2a0
      
       but task is already holding lock:
        (rtnl_mutex){+.+.+.}, at: [<ffffffff813bd7d2>] rtnl_lock+0x12/0x20
      
       which lock already depends on the new lock.
       [ INFO: possible circular locking dependency detected ]
       ======================================================
      
      The full output is available at http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00060.html.
      To summarize, commit 6b6fa586 added a 'cancel_work_sync(&wl->firmware_load)'
      call in the wrong place.
      
      The fix is to move the cancel_work_sync() call to b43_bcma_remove() and
      b43_ssb_remove(). Thanks to Johannes Berg and Michael Buesch for help in
      diagnosing the log output.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org> [V3.5+]
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63a02ce1
  22. 07 Jan, 2013 1 commit
    • Larry Finger's avatar
      b43: Fix firmware loading when driver is built into the kernel · 5e20a4b5
      Larry Finger authored
      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: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org>  (V3.4+)
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5e20a4b5
  23. 10 Dec, 2012 1 commit
  24. 24 Oct, 2012 1 commit
  25. 19 Oct, 2012 1 commit