1. 13 Oct, 2018 1 commit
  2. 26 Sep, 2018 1 commit
  3. 05 Sep, 2018 1 commit
  4. 15 Aug, 2018 1 commit
    • Andi Kleen's avatar
      x86/speculation/l1tf: Add sysfs reporting for l1tf · 432e99b3
      Andi Kleen authored
      commit 17dbca119312b4e8173d4e25ff64262119fcef38 upstream
      L1TF core kernel workarounds are cheap and normally always enabled, However
      they still should be reported in sysfs if the system is vulnerable or
      mitigated. Add the necessary CPU feature/bug bits.
      - Extend the existing checks for Meltdowns to determine if the system is
        vulnerable. All CPUs which are not vulnerable to Meltdown are also not
        vulnerable to L1TF
      - Check for 32bit non PAE and emit a warning as there is no practical way
        for mitigation due to the limited physical address bits
      - If the system has more than MAX_PA/2 physical memory the invert page
        workarounds don't protect the system against the L1TF attack anymore,
        because an inverted physical address will also point to valid
        memory. Print a warning in this case and report that the system is
      Add a function which returns the PFN limit for the L1TF mitigation, which
      will be used in follow up patches for sanity and range checks.
      [ tglx: Renamed the CPU feature bit to L1TF_PTEINV ]
      [ dwmw2: Backport to 4.9 (cpufeatures.h, E820) ]
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarDave Hansen <dave.hansen@intel.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 28 Jul, 2018 1 commit
    • Rafael J. Wysocki's avatar
      driver core: Partially revert "driver core: correct device's shutdown order" · bf0070e2
      Rafael J. Wysocki authored
      commit 722e5f2b1eec7de61117b7c0a7914761e3da2eda upstream.
      Commit 52cdbdd4 (driver core: correct device's shutdown order)
      introduced a regression by breaking device shutdown on some systems.
      Namely, the devices_kset_move_last() call in really_probe() added by
      that commit is a mistake as it may cause parents to follow children
      in the devices_kset list which then causes shutdown to fail.  For
      example, if a device has children before really_probe() is called
      for it (which is not uncommon), that call will cause it to be
      reordered after the children in the devices_kset list and the
      ordering of that list will not reflect the correct device shutdown
      order any more.
      Also it causes the devices_kset list to be constantly reordered
      until all drivers have been probed which is totally pointless
      overhead in the majority of cases and it only covered an issue
      with system shutdown, while system-wide suspend/resume potentially
      had the same issue on the affected platforms (which was not covered).
      Moreover, the shutdown issue originally addressed by the change in
      really_probe() made by commit 52cdbdd4 is not present in 4.18-rc
      any more, since dra7 started to use the sdhci-omap driver which
      doesn't disable any regulators during shutdown, so the really_probe()
      part of commit 52cdbdd4 can be safely reverted.  [The original
      issue was related to the omap_hsmmc driver used by dra7 previously.]
      For the above reasons, revert the really_probe() modifications made
      by commit 52cdbdd4.
      The other code changes made by commit 52cdbdd4 are useful and
      they need not be reverted.
      Fixes: 52cdbdd4 (driver core: correct device's shutdown order)
      Link: https://lore.kernel.org/lkml/CAFgQCTt7VfqM=UyCnvNFxrSw8Z6cUtAi3HUwR4_xPAc03SgHjQ@mail.gmail.com/Reported-by: default avatarPingfan Liu <kernelfans@gmail.com>
      Tested-by: default avatarPingfan Liu <kernelfans@gmail.com>
      Reviewed-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. 11 Jul, 2018 1 commit
    • Waldemar Rymarkiewicz's avatar
      PM / OPP: Update voltage in case freq == old_freq · 6989d407
      Waldemar Rymarkiewicz authored
      commit c5c2a97b3ac7d1ec19e7cff9e38caca6afefc3de upstream.
      This commit fixes a rare but possible case when the clk rate is updated
      without update of the regulator voltage.
      At boot up, CPUfreq checks if the system is running at the right freq. This
      is a sanity check in case a bootloader set clk rate that is outside of freq
      table present with cpufreq core. In such cases system can be unstable so
      better to change it to a freq that is preset in freq-table.
      The CPUfreq takes next freq that is >= policy->cur and this is our
      target_freq that needs to be set now.
      dev_pm_opp_set_rate(dev, target_freq) checks the target_freq and the
      old_freq (a current rate). If these are equal it returns early. If not,
      it searches for OPP (old_opp) that fits best to old_freq (not listed in
      the table) and updates old_freq (!).
      Here, we can end up with old_freq = old_opp.rate = target_freq, which
      is not handled in _generic_set_opp_regulator(). It's supposed to update
      voltage only when freq > old_freq  || freq > old_freq.
      if (freq > old_freq) {
      		ret = _set_opp_voltage(dev, reg, new_supply);
      if (freq < old_freq) {
      		ret = _set_opp_voltage(dev, reg, new_supply);
      		if (ret)
      It results in, no voltage update while clk rate is updated.
      freq-table = {
      	1000MHz   1.15V
      	 666MHZ   1.10V
      	 333MHz   1.05V
      boot-up-freq        = 800MHz   # not listed in freq-table
      freq = target_freq  = 1GHz
      old_freq            = 800Mhz
      old_opp = _find_freq_ceil(opp_table, &old_freq);  #(old_freq is modified!)
      old_freq            = 1GHz
      Fixes: 6a0712f6 ("PM / OPP: Add dev_pm_opp_set_rate()")
      Cc: 4.6+ <stable@vger.kernel.org> # v4.6+
      Signed-off-by: default avatarWaldemar Rymarkiewicz <waldemar.rymarkiewicz@gmail.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. 26 Jun, 2018 1 commit
  8. 30 May, 2018 1 commit
  9. 22 May, 2018 1 commit
  10. 24 Apr, 2018 1 commit
  11. 31 Jan, 2018 2 commits
    • Sudeep Holla's avatar
      drivers: base: cacheinfo: fix boot error message when acpi is enabled · 1d8c402e
      Sudeep Holla authored
      commit 55877ef4 upstream.
      ARM64 enables both CONFIG_OF and CONFIG_ACPI and the firmware can pass
      both ACPI tables and the device tree. Based on the kernel parameter, one
      of the two will be chosen. If acpi is enabled, then device tree is not
      Currently ARM64 platforms report:
      	Failed to find cpu0 device node
      	Unable to detect cache hierarchy from DT for CPU 0
      which is incorrect when booting with ACPI. Also latest ACPI v6.1 has no
      support for cache properties/hierarchy.
      This patch adds check for unflattened device tree and also returns as
      "not supported" if ACPI is runtime enabled.
      It also removes the reference to DT from the error message as the cache
      hierarchy can be detected from the firmware(OF/DT/ACPI)
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarMian Yousaf Kaukab <yousaf.kaukab@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Sudeep Holla's avatar
      drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled · f5aaa5a2
      Sudeep Holla authored
      commit fac51482 upstream.
      With CONFIG_OF enabled on x86, we get the following error on boot:
      	Failed to find cpu0 device node
       	Unable to detect cache hierarchy from DT for CPU 0
      and the cacheinfo fails to get populated in the corresponding sysfs
      entries. This is because cache_setup_of_node looks for of_node for
      setting up the shared cpu_map without checking that it's already
      populated in the architecture specific callback.
      In order to indicate that the shared cpu_map is already populated, this
      patch introduces a boolean `cpu_map_populated` in struct cpu_cacheinfo
      that can be used by the generic code to skip cache_shared_cpu_map_setup.
      This patch also sets that boolean for x86.
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarMian Yousaf Kaukab <yousaf.kaukab@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. 17 Jan, 2018 1 commit
  13. 25 Dec, 2017 1 commit
  14. 14 Dec, 2017 1 commit
  15. 08 Dec, 2017 1 commit
  16. 30 Nov, 2017 1 commit
  17. 15 Nov, 2017 1 commit
  18. 08 Nov, 2017 1 commit
  19. 18 Oct, 2017 1 commit
    • Jarkko Nikula's avatar
      device property: Track owner device of device property · 2a077f72
      Jarkko Nikula authored
      commit 5ab894ae upstream.
      Deletion of subdevice will remove device properties associated to parent
      when they share the same firmware node after commit 478573c9 (driver
      core: Don't leak secondary fwnode on device removal).  This was observed
      with a driver adding subdevice that driver wasn't able to read device
      properties after rmmod/modprobe cycle.
      Consider the lifecycle of it:
      parent device registration
      		set_secondary_fwnode(dev, &p->fwnode)
      parent probe
      	read device properties
      	ACPI_COMPANION_SET(subdevice, ACPI_COMPANION(parent))
      parent remove
      			set_secondary_fwnode(dev, NULL);
      Parent device will have its primary firmware node pointing to an ACPI
      node and secondary firmware node point to device properties.
      ACPI_COMPANION_SET() call in parent probe will set the subdevice's
      firmware node to point to the same 'struct fwnode_handle' and the
      associated secondary firmware node, i.e. the device properties as the
      When subdevice is deleted in parent remove that will remove those
      device properties and attempt to read device properties in next
      parent probe call will fail.
      Fix this by tracking the owner device of device properties and delete
      them only when owner device is being deleted.
      Fixes: 478573c9 (driver core: Don't leak secondary fwnode on device removal)
      Signed-off-by: default avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  20. 12 Oct, 2017 1 commit
  21. 05 Oct, 2017 1 commit
  22. 09 Sep, 2017 1 commit
  23. 28 Aug, 2017 1 commit
    • Philippe Gerum's avatar
      ipipe: printk: enable dev_printk() from the head stage · dee05ea6
      Philippe Gerum authored
      Calling dev_{info,warn,err}() is currently invalid, as vprintk_emit()
      eventually operates on regular kernel resources.
      If called from the head stage, or with hard irqs disabled in presence
      of a head stage, route all dev_printk() requests to our deferred
      logging mechanism already used for printk() instead. This means that
      we won't syslog the output in such a case, but at least we will have a
      feedback on the console device, without doing anything silly in the
  24. 11 Aug, 2017 1 commit
  25. 27 Jul, 2017 4 commits
  26. 21 Jul, 2017 2 commits
  27. 15 Jul, 2017 1 commit
  28. 12 Jul, 2017 1 commit
  29. 17 Jun, 2017 1 commit
    • Rafael J. Wysocki's avatar
      PM / runtime: Avoid false-positive warnings from might_sleep_if() · 36d9659c
      Rafael J. Wysocki authored
      [ Upstream commit a9306a63 ]
      The might_sleep_if() assertions in __pm_runtime_idle(),
      __pm_runtime_suspend() and __pm_runtime_resume() may generate
      false-positive warnings in some situations.  For example, that
      happens if a nested pm_runtime_get_sync()/pm_runtime_put() pair
      is executed with disabled interrupts within an outer
      pm_runtime_get_sync()/pm_runtime_put() section for the same device.
      [Generally, pm_runtime_get_sync() may sleep, so it should not be
      called with disabled interrupts, but in this particular case the
      previous pm_runtime_get_sync() guarantees that the device will not
      be suspended, so the inner pm_runtime_get_sync() will return
      immediately after incrementing the device's usage counter.]
      That started to happen in the i915 driver in 4.10-rc, leading to
      the following splat:
       BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1032
       in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
       1 lock held by Xorg/1500:
        #0:  (&dev->struct_mutex){+.+.+.}, at:
        [<ffffffffa0680c13>] i915_mutex_lock_interruptible+0x43/0x140 [i915]
       CPU: 0 PID: 1500 Comm: Xorg Not tainted
       Call Trace:
        intel_runtime_pm_get+0x25/0x90 [i915]
        aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
        i915_vma_bind+0xaf/0x1e0 [i915]
        i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
        i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
        ? trace_hardirqs_on+0xd/0x10
        ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
        ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
        i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
        ? __might_fault+0x4e/0xb0
        i915_gem_execbuffer2+0xc5/0x260 [i915]
        ? __might_fault+0x4e/0xb0
        drm_ioctl+0x206/0x450 [drm]
        ? i915_gem_execbuffer+0x340/0x340 [i915]
        ? __fget+0x5/0x200
        ? __fget+0x111/0x200
        ? __fget+0x5/0x200
      even though the code triggering it is correct.
      Unfortunately, the might_sleep_if() assertions in question are
      too coarse-grained to cover such cases correctly, so make them
      a bit less sensitive in order to avoid the false-positives.
      Reported-and-tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  30. 09 Feb, 2017 1 commit
    • Toshi Kani's avatar
      base/memory, hotplug: fix a kernel oops in show_valid_zones() · 6cb0497a
      Toshi Kani authored
      commit a96dfddb upstream.
      Reading a sysfs "memoryN/valid_zones" file leads to the following oops
      when the first page of a range is not backed by struct page.
      show_valid_zones() assumes that 'start_pfn' is always valid for
       BUG: unable to handle kernel paging request at ffffea017a000000
       IP: show_valid_zones+0x6f/0x160
      This issue may happen on x86-64 systems with 64GiB or more memory since
      their memory block size is bumped up to 2GiB.  [1] An example of such
      systems is desribed below.  0x3240000000 is only aligned by 1GiB and
      this memory block starts from 0x3200000000, which is not backed by
      struct page.
       BIOS-e820: [mem 0x0000003240000000-0x000000603fffffff] usable
      Since test_pages_in_a_zone() already checks holes, fix this issue by
      extending this function to return 'valid_start' and 'valid_end' for a
      given range.  show_valid_zones() then proceeds with the valid range.
      [1] 'Commit bdee237c ("x86: mm: Use 2GB memory block size on
          large-memory x86-64 systems")'
      Link: http://lkml.kernel.org/r/20170127222149.30893-3-toshi.kani@hpe.comSigned-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Zhang Zhen <zhenzhang.zhang@huawei.com>
      Cc: Reza Arbab <arbab@linux.vnet.ibm.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  31. 01 Feb, 2017 1 commit
    • Yasuaki Ishimatsu's avatar
      memory_hotplug: make zone_can_shift() return a boolean value · 143a9ad4
      Yasuaki Ishimatsu authored
      commit 8a1f780e upstream.
      online_{kernel|movable} is used to change the memory zone to
      ZONE_{NORMAL|MOVABLE} and online the memory.
      To check that memory zone can be changed, zone_can_shift() is used.
      Currently the function returns minus integer value, plus integer
      value and 0. When the function returns minus or plus integer value,
      it means that the memory zone can be changed to ZONE_{NORNAL|MOVABLE}.
      But when the function returns 0, there are two meanings.
      One of the meanings is that the memory zone does not need to be changed.
      For example, when memory is in ZONE_NORMAL and onlined by online_kernel
      the memory zone does not need to be changed.
      Another meaning is that the memory zone cannot be changed. When memory
      is in ZONE_NORMAL and onlined by online_movable, the memory zone may
      not be changed to ZONE_MOVALBE due to memory online limitation(see
      Documentation/memory-hotplug.txt). In this case, memory must not be
      The patch changes the return type of zone_can_shift() so that memory
      online operation fails when memory zone cannot be changed as follows:
      Before applying patch:
         # grep -A 35 "Node 2" /proc/zoneinfo
         Node 2, zone   Normal
            node_scanned  0
                 spanned  8388608
                 present  7864320
                 managed  7864320
         # echo online_movable > memory4097/state
         # grep -A 35 "Node 2" /proc/zoneinfo
         Node 2, zone   Normal
            node_scanned  0
                 spanned  8388608
                 present  8388608
                 managed  8388608
         online_movable operation succeeded. But memory is onlined as
      After applying patch:
         # grep -A 35 "Node 2" /proc/zoneinfo
         Node 2, zone   Normal
            node_scanned  0
                 spanned  8388608
                 present  7864320
                 managed  7864320
         # echo online_movable > memory4097/state
         bash: echo: write error: Invalid argument
         # grep -A 35 "Node 2" /proc/zoneinfo
         Node 2, zone   Normal
            node_scanned  0
                 spanned  8388608
                 present  7864320
                 managed  7864320
         online_movable operation failed because of failure of changing
         the memory zone from ZONE_NORMAL to ZONE_MOVABLE
      Fixes: df429ac0 ("memory-hotplug: more general validation of zone during online")
      Link: http://lkml.kernel.org/r/2f9c3837-33d7-b6e5-59c0-6ca4372b2d84@gmail.comSigned-off-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Reviewed-by: default avatarReza Arbab <arbab@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  32. 12 Jan, 2017 1 commit
    • Tony Lindgren's avatar
      PM / wakeirq: Fix dedicated wakeirq for drivers not using autosuspend · 65f79683
      Tony Lindgren authored
      commit bed57030 upstream.
      I noticed some wakeirq flakeyness with consumer drivers not using
      autosuspend. For drivers not using autosuspend, the wakeirq may never
      get unmasked in rpm_suspend() because of irq desc->depth.
      We are configuring dedicated wakeirqs to start with IRQ_NOAUTOEN as we
      naturally don't want them running until rpm_suspend() is called.
      However, when a consumer driver initially calls pm_runtime_get(), we
      now wrongly start with disable_irq_nosync() call on the dedicated
      wakeirq that is disabled to start with.
      This causes desc->depth to toggle between 1 and 2 instead of the usual
      0 and 1. This can prevent enable_irq() from unmasking the wakeirq as
      that only happens at desc->depth 1.
      This does not necessarily show up with drivers using autosuspend as
      there is time for disable_irq_nosync() before rpm_suspend() gets called
      after the autosuspend timeout.
      Let's fix the issue by adding wirq->status that lazily gets set on
      the first rpm_suspend(). We also need PM runtime core private functions
      for dev_pm_enable_wake_irq_check() and dev_pm_disable_wake_irq_check()
      so we can enable the dedicated wakeirq on the first rpm_suspend().
      While at it, let's also fix the comments for dev_pm_enable_wake_irq()
      and dev_pm_disable_wake_irq(). Those can still be used by the consumer
      drivers as needed because the IRQ core manages the interrupt usecount
      for us.
      Fixes: 4990d4fe (PM / Wakeirq: Add automated device wake IRQ handling)
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  33. 09 Jan, 2017 1 commit
    • Yves-Alexis Perez's avatar
      firmware: fix usermode helper fallback loading · b3854cef
      Yves-Alexis Perez authored
      commit 2e700f8d upstream.
      When you use the firmware usermode helper fallback with a timeout value set to a
      value greater than INT_MAX (2147483647) a cast overflow issue causes the
      timeout value to go negative and breaks all usermode helper loading. This
      regression was introduced through commit 68ff2a00 ("firmware_loader:
      handle timeout via wait_for_completion_interruptible_timeout()") on kernel
      The firmware_class drivers relies on the firmware usermode helper
      fallback as a mechanism to look for firmware if the direct filesystem
      search failed only if:
        a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros):
        Then all of these callers will rely on the fallback mechanism in case
        the firmware is not found through an initial direct filesystem lookup:
        o request_firmware()
        o request_firmware_into_buf()
        o request_firmware_nowait()
        b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros):
        Then only callers using request_firmware_nowait() with the second
        argument set to false, this explicitly is requesting the UMH firmware
        fallback to be relied on in case the first filesystem lookup fails.
        Using Coccinelle SmPL grammar we have identified only two drivers
        explicitly requesting the UMH firmware fallback mechanism:
        - drivers/firmware/dell_rbu.c
        - drivers/leds/leds-lp55xx-common.c
      Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the
      biggest impact of this regression are users of the dell_rbu and
      leds-lp55xx-common device driver which required the UMH to find their
      respective needed firmwares.
      The default timeout for the UMH is set to 60 seconds always, as of
      commit 68ff2a00 ("firmware_loader: handle timeout via
      wait_for_completion_interruptible_timeout()") the timeout was bumped
      to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET
      value was also used if the timeout was configured by a user to 0.
      The following works:
      echo 2147483647 > /sys/class/firmware/timeout
      But both of the following set the timeout to MAX_JIFFY_OFFSET even if
      we display 0 back to userspace:
      echo 2147483648 > /sys/class/firmware/timeout
      cat /sys/class/firmware/timeout
      echo 0> /sys/class/firmware/timeout
      cat /sys/class/firmware/timeout
      A max value of INT_MAX (2147483647) seconds is therefore implicit due to the
      another cast with simple_strtol().
      This fixes the secondary cast (the first one is simple_strtol() but its an
      issue only by forcing an implicit limit) by re-using the timeout variable and
      only setting retval in appropriate cases.
      Lastly worth noting systemd had ripped out the UMH firmware fallback
      mechanism from udev since udev 2014 via commit be2ea723b1d023b3d
      ("udev: remove userspace firmware loading support"), so as of systemd v217.
      Signed-off-by: default avatarYves-Alexis Perez <corsac@corsac.net>
      Fixes: 68ff2a00 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()"
      Cc: Luis R. Rodriguez <mcgrof@kernel.org>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Reviewed-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      [mcgrof@kernel.org: gave commit log a whole lot of love]
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  34. 06 Jan, 2017 2 commits