1. 13 Jun, 2017 1 commit
  2. 12 Jun, 2017 14 commits
  3. 10 Jun, 2017 1 commit
  4. 09 Jun, 2017 20 commits
  5. 07 Jun, 2017 1 commit
  6. 03 Jun, 2017 3 commits
    • Luis R. Rodriguez's avatar
      firmware: move umh try locks into the umh code · 06a45a93
      Luis R. Rodriguez authored
      This moves the usermode helper locks into only code paths that use the
      usermode helper API from the kernel. The usermode helper locks were
      originally added to prevent stalling suspend, later the firmware cache
      was added to help with this, and further later direct filesystem lookup
      was added by Linus to completely bypass udev due to the amount of issues
      the umh approach had.
      
      The usermode helper locks were kept even when the direct filesystem lookup
      mechanism is used though. A lot has changed since the original usermode
      helper locks were added but the recent commit which added the code for
      firmware_enabled() are intended to address any possible races cured only
      as collateral by using the locks as though side consequence of code
      evolution and this not being addressed any time sooner. With the
      firmware_enabled() code in place we are a bit more sure to move the
      usermode helper locks to UMH only code.
      
      There is a bit of history here so let's recap a bit of it to ensure nothing
      is lost and things are clear. The direct filesystem approach to loading
      firmware is rather new, it was added via commit abb139e7 ("firmware:
      teach the kernel to load firmware files directly from the filesystem") by
      Linus merged on the v3.7 release, to enable to bypass udev.
      
      usermodehelper_read_lock_wait() was added earlier via commit 9b78c1da
      ("firmware_class: Do not warn that system is not ready from async loads")
      merged on v3.4, after Rafael noted that the async firmware API call
      request_firmware_nowait() should not be penalized to fail if userspace is
      not available yet or frozen, it'd allow for a timeout grace period before
      giving up. The WARN_ON() was kept for the sync firmware API call though on
      request_firmware(). At this time there was no direct filesystem lookup for
      firmware though.
      
      The original usermode helper lock came from commit a144c6a6 ("PM:
      Print a warning if firmware is requested when tasks are frozen") merged on
      the v3.0 kernel by Rafael to print a warning back when firmware requests
      were used on resume(), thaw() or restore() callbacks and there was no
      direct fs lookups or the firmware cache.
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06a45a93
    • Luis R. Rodriguez's avatar
      firmware: move assign_firmware_buf() further up · 8509adca
      Luis R. Rodriguez authored
      This will make subsequent changes easier to read.
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8509adca
    • Luis R. Rodriguez's avatar
      firmware: add sanity check on shutdown/suspend · 81f95076
      Luis R. Rodriguez authored
      The firmware API should not be used after we go to suspend
      and after we reboot/halt. The suspend/resume case is a bit
      complex, so this documents that so things are clearer.
      
      We want to know about users of the API in incorrect places so
      that their callers are corrected, so this also adds a warn
      for those cases.
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81f95076