linux-stable.git/drivers/base, branch v5.8.7

device property: Fix the secondary firmware node handling in set_primary_fwnode()

2020-09-03T09:29:44+00:00

commit c15e1bdda4365a5f17cdadf22bf1c1df13884a9e upstream.

When the primary firmware node pointer is removed from a
device (set to NULL) the secondary firmware node pointer,
when it exists, is made the primary node for the device.
However, the secondary firmware node pointer of the original
primary firmware node is never cleared (set to NULL).

To avoid situation where the secondary firmware node pointer
is pointing to a non-existing object, clearing it properly
when the primary node is removed from a device in
set_primary_fwnode().

Fixes: 97badf873ab6 ("device property: Make it possible to use secondary firmware nodes")
Cc: All applicable 
Signed-off-by: Heikki Krogerus 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM: sleep: core: Fix the handling of pending runtime resume requests

2020-09-03T09:29:43+00:00

commit e3eb6e8fba65094328b8dca635d00de74ba75b45 upstream.

It has been reported that system-wide suspend may be aborted in the
absence of any wakeup events due to unforseen interactions of it with
the runtume PM framework.

One failing scenario is when there are multiple devices sharing an
ACPI power resource and runtime-resume needs to be carried out for
one of them during system-wide suspend (for example, because it needs
to be reconfigured before the whole system goes to sleep).  In that
case, the runtime-resume of that device involves turning the ACPI
power resource "on" which in turn causes runtime-resume requests
to be queued up for all of the other devices sharing it.  Those
requests go to the runtime PM workqueue which is frozen during
system-wide suspend, so they are not actually taken care of until
the resume of the whole system, but the pm_runtime_barrier()
call in __device_suspend() sees them and triggers system wakeup
events for them which then cause the system-wide suspend to be
aborted if wakeup source objects are in active use.

Of course, the logic that leads to triggering those wakeup events is
questionable in the first place, because clearly there are cases in
which a pending runtime resume request for a device is not connected
to any real wakeup events in any way (like the one above).  Moreover,
it is racy, because the device may be resuming already by the time
the pm_runtime_barrier() runs and so if the driver doesn't take care
of signaling the wakeup event as appropriate, it will be lost.
However, if the driver does take care of that, the extra
pm_wakeup_event() call in the core is redundant.

Accordingly, drop the conditional pm_wakeup_event() call fron
__device_suspend() and make the latter call pm_runtime_barrier()
alone.  Also modify the comment next to that call to reflect the new
code and extend it to mention the need to avoid unwanted interactions
between runtime PM and system-wide device suspend callbacks.

Fixes: 1e2ef05bb8cf8 ("PM: Limit race conditions between runtime PM and system sleep (v2)")
Signed-off-by: Rafael J. Wysocki 
Acked-by: Alan Stern 
Reported-by: Utkarsh H Patel 
Tested-by: Utkarsh H Patel 
Tested-by: Pengfei Xu 
Cc: All applicable 
Signed-off-by: Greg Kroah-Hartman

driver core: Avoid binding drivers to dead devices

2020-08-21T11:14:57+00:00

commit 654888327e9f655a9d55ad477a9583e90e8c9b5c upstream.

Commit 3451a495ef24 ("driver core: Establish order of operations for
device_add and device_del via bitflag") sought to prevent asynchronous
driver binding to a device which is being removed.  It added a
per-device "dead" flag which is checked in the following code paths:

* asynchronous binding in __driver_attach_async_helper()
*  synchronous binding in device_driver_attach()
* asynchronous binding in __device_attach_async_helper()

It did *not* check the flag upon:

*  synchronous binding in __device_attach()

However __device_attach() may also be called asynchronously from:

deferred_probe_work_func()
  bus_probe_device()
    device_initial_probe()
      __device_attach()

So if the commit's intention was to check the "dead" flag in all
asynchronous code paths, then a check is also necessary in
__device_attach().  Add the missing check.

Fixes: 3451a495ef24 ("driver core: Establish order of operations for device_add and device_del via bitflag")
Signed-off-by: Lukas Wunner 
Cc: stable@vger.kernel.org # v5.1+
Cc: Alexander Duyck 
Link: https://lore.kernel.org/r/de88a23a6fe0ef70f7cfd13c8aea9ab51b4edab6.1594214103.git.lukas@wunner.de
Signed-off-by: Greg Kroah-Hartman

firmware_loader: EFI firmware loader must handle pre-allocated buffer

2020-08-19T06:27:08+00:00

commit 4fb60b158afd3ac9e0fe9975aa476213f5cc0a4d upstream.

The EFI platform firmware fallback would clobber any pre-allocated
buffers. Instead, correctly refuse to reallocate when too small (as
already done in the sysfs fallback), or perform allocation normally
when needed.

Fixes: e4c2c0ff00ec ("firmware: Add new platform fallback mechanism and firmware_request_platform()")
Cc: stable@vger.kernel.org
Acked-by: Scott Branden 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20200724213640.389191-4-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman

driver core: Fix probe_count imbalance in really_probe()

2020-08-19T06:27:03+00:00

commit b292b50b0efcc7095d8bf15505fba6909bb35dce upstream.

syzbot is reporting hung task in wait_for_device_probe() [1]. At least,
we always need to decrement probe_count if we incremented probe_count in
really_probe().

However, since I can't find "Resources present before probing" message in
the console log, both "this message simply flowed off" and "syzbot is not
hitting this path" will be possible. Therefore, while we are at it, let's
also prepare for concurrent wait_for_device_probe() calls by replacing
wake_up() with wake_up_all().

[1] https://syzkaller.appspot.com/bug?id=25c833f1983c9c1d512f4ff860dd0d7f5a2e2c0f

Reported-by: syzbot 
Fixes: 7c35e699c88bd607 ("driver core: Print device when resources present in really_probe()")
Cc: Geert Uytterhoeven 
Signed-off-by: Tetsuo Handa 
Cc: stable 
Link: https://lore.kernel.org/r/20200713021254.3444-1-penguin-kernel@I-love.SAKURA.ne.jp
Signed-off-by: Greg Kroah-Hartman

device property: Avoid NULL pointer dereference in device_get_next_child_node()

2020-07-23T15:04:28+00:00

When we have no primary fwnode or when it's a software node, we may end up
in the situation when fwnode is a NULL pointer. There is no point to look for
secondary fwnode in such case. Add a necessary check to a condition.

Fixes: 114dbb4fa7c4 ("drivers property: When no children in primary, try secondary")
Reported-by: Maxim Levitsky 
Signed-off-by: Andy Shevchenko 
Tested-by: Maxim Levitsky 
Link: https://lore.kernel.org/r/20200716182747.54929-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

Merge tag 'regmap-fix-v5.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap into master

2020-07-17T16:58:18+00:00

Pull regmap fixes from Mark Brown:
 "A couple of substantial fixes here, one from Doug which fixes the
  debugfs code for MMIO regmaps (fortunately not the common case) and
  one from Marc fixing lookups of multiple regmaps for the same device
  (a very unusual case).

  There's also a fix for Kconfig to ensure we enable SoundWire properly"

* tag 'regmap-fix-v5.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: debugfs: Don't sleep while atomic for fast_io regmaps
  regmap: add missing dependency on SoundWire
  regmap: dev_get_regmap_match(): fix string comparison

regmap: debugfs: Don't sleep while atomic for fast_io regmaps

2020-07-16T19:41:58+00:00

If a regmap has "fast_io" set then its lock function uses a spinlock.
That doesn't work so well with the functions:
* regmap_cache_only_write_file()
* regmap_cache_bypass_write_file()

Both of the above functions have the pattern:
1. Lock the regmap.
2. Call:
   debugfs_write_file_bool()
     copy_from_user()
       __might_fault()
         __might_sleep()

Let's reorder things a bit so that we do all of our sleepable
functions before we grab the lock.

Fixes: d3dc5430d68f ("regmap: debugfs: Allow writes to cache state settings")
Signed-off-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20200715164611.1.I35b3533e8a80efde0cec1cc70f71e1e74b2fa0da@changeid
Signed-off-by: Mark Brown

driver core: Avoid deferred probe due to fw_devlink_pause/resume()

2020-07-10T13:20:38+00:00

With the earlier patch in this series, all devices that deferred probe
due to fw_devlink_pause() will have their probes delayed till the
deferred probe thread is kicked off during late_initcall. This will also
affect all their consumers.

This delayed probing in unnecessary. So this patch just keeps track of
the devices that had their probe deferred due to fw_devlink_pause() and
attempts to probe them once during fw_devlink_resume().

Fixes: 716a7a259690 ("driver core: fw_devlink: Add support for batching fwnode parsing")
Signed-off-by: Saravana Kannan 
Tested-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/20200701194259.3337652-4-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman

driver core: Rename dev_links_info.defer_sync to defer_hook

2020-07-10T13:20:38+00:00

The defer_sync field is used as a hook to add the device to the
deferred_sync list. Rename it so that it's more meaningful for the next
patch that'll also use this field as a hook to a deferred_fw_devlink
list.

Signed-off-by: Saravana Kannan 
Reviewed-by: Rafael J. Wysocki 
Tested-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/20200701194259.3337652-3-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman