linux-stable.git/drivers/base/power, branch linux-6.16.y Linux kernel stable tree PM: runtime: Take active children into account in pm_runtime_get_if_in_use() 2025-08-28T14:34:12+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2025-07-09T10:41:45+00:00 e753e3534e6caf060c0ae3793f5761f81813e896 commit 51888393cc64dd0462d0b96c13ab94873abbc030 upstream. For all practical purposes, there is no difference between the situation in which a given device is not ignoring children and its active child count is nonzero and the situation in which its runtime PM usage counter is nonzero. However, pm_runtime_get_if_in_use() will only increment the device's usage counter and return 1 in the latter case. For consistency, make it do so in the former case either by adjusting pm_runtime_get_conditional() and update the related kerneldoc comments accordingly. Fixes: c111566bea7c ("PM: runtime: Add pm_runtime_get_if_active()") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: 5.10+ <stable@vger.kernel.org> # 5.10+: c0ef3df8dbae: PM: runtime: Simplify pm_runtime_get_if_active() usage Cc: 5.10+ <stable@vger.kernel.org> # 5.10+ Link: https://patch.msgid.link/12700973.O9o76ZdvQC@rjwysocki.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 51888393cc64dd0462d0b96c13ab94873abbc030 upstream.

For all practical purposes, there is no difference between the situation
in which a given device is not ignoring children and its active child
count is nonzero and the situation in which its runtime PM usage counter
is nonzero.  However, pm_runtime_get_if_in_use() will only increment the
device's usage counter and return 1 in the latter case.

For consistency, make it do so in the former case either by adjusting
pm_runtime_get_conditional() and update the related kerneldoc comments
accordingly.

Fixes: c111566bea7c ("PM: runtime: Add pm_runtime_get_if_active()")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: 5.10+ <stable@vger.kernel.org> # 5.10+: c0ef3df8dbae: PM: runtime: Simplify pm_runtime_get_if_active() usage
Cc: 5.10+ <stable@vger.kernel.org> # 5.10+
Link: https://patch.msgid.link/12700973.O9o76ZdvQC@rjwysocki.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PM: runtime: Clear power.needs_force_resume in pm_runtime_reinit() 2025-08-20T16:41:00+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2025-06-27T19:16:05+00:00 f16e42f6b09bfdb1bffb3cd15590396676277938 [ Upstream commit 89d9cec3b1e9c49bae9375a2db6dc49bc7468af0 ] Clear power.needs_force_resume in pm_runtime_reinit() in case it has been set by pm_runtime_force_suspend() invoked from a driver remove callback. Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://patch.msgid.link/9495163.CDJkKcVGEf@rjwysocki.net Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 89d9cec3b1e9c49bae9375a2db6dc49bc7468af0 ]

Clear power.needs_force_resume in pm_runtime_reinit() in case it has
been set by pm_runtime_force_suspend() invoked from a driver remove
callback.

Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/9495163.CDJkKcVGEf@rjwysocki.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
PM: sleep: Update power.completion for all devices on errors 2025-07-15T12:55:11+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2025-07-14T17:45:31+00:00 ebd6884167eac94bae9f92793fcd84069d9e4415 After commit aa7a9275ab81 ("PM: sleep: Suspend async parents after suspending children"), the following scenario is possible: 1. Device A is async and it depends on device B that is sync. 2. Async suspend is scheduled for A before the processing of B is started. 3. A is waiting for B. 4. In the meantime, an unrelated device fails to suspend and returns an error. 5. The processing of B doesn't start at all and its power.completion is not updated. 6. A is still waiting for B when async_synchronize_full() is called. 7. Deadlock ensues. To prevent this from happening, update power.completion for all devices on errors in all suspend phases, but do not do it directly for devices that are already being processed or are waiting for the processing to start because in those cases it may be necessary to wait for the processing to actually complete before updating power.completion for the device. Fixes: aa7a9275ab81 ("PM: sleep: Suspend async parents after suspending children") Fixes: 443046d1ad66 ("PM: sleep: Make suspend of devices more asynchronous") Closes: https://lore.kernel.org/linux-pm/e13740a0-88f3-4a6f-920f-15805071a7d6@linaro.org/ Reported-and-tested-by: Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://patch.msgid.link/6191258.lOV4Wx5bFT@rjwysocki.net 
After commit aa7a9275ab81 ("PM: sleep: Suspend async parents after
suspending children"), the following scenario is possible:

 1. Device A is async and it depends on device B that is sync.
 2. Async suspend is scheduled for A before the processing of B is
    started.
 3. A is waiting for B.
 4. In the meantime, an unrelated device fails to suspend and returns
    an error.
 5. The processing of B doesn't start at all and its power.completion is
    not updated.
 6. A is still waiting for B when async_synchronize_full() is called.
 7. Deadlock ensues.

To prevent this from happening, update power.completion for all devices
on errors in all suspend phases, but do not do it directly for devices
that are already being processed or are waiting for the processing to
start because in those cases it may be necessary to wait for the
processing to actually complete before updating power.completion for
the device.

Fixes: aa7a9275ab81 ("PM: sleep: Suspend async parents after suspending children")
Fixes: 443046d1ad66 ("PM: sleep: Make suspend of devices more asynchronous")
Closes: https://lore.kernel.org/linux-pm/e13740a0-88f3-4a6f-920f-15805071a7d6@linaro.org/
Reported-and-tested-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/6191258.lOV4Wx5bFT@rjwysocki.net
PM: sleep: Call pm_restore_gfp_mask() after dpm_resume() 2025-07-09T20:53:06+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2025-07-09T17:12:47+00:00 ec3cae639482a8da11a3ae30d28ceceb9d6a3f56 Commit 12ffc3b1513e ("PM: Restrict swap use to later in the suspend sequence") changed two pm_restore_gfp_mask() calls in enter_state() and hibernation_restore() into one pm_restore_gfp_mask() call in dpm_resume_end(), but it put that call before the dpm_resume() invocation which is too early (some swap-backing devices may not be ready at that point). Moreover, this code ordering change was not even mentioned in the changelog of the commit mentioned above. Address this by moving that call after the dpm_resume() one. Fixes: 12ffc3b1513e ("PM: Restrict swap use to later in the suspend sequence") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/2797018.mvXUDI8C0e@rjwysocki.net 
Commit 12ffc3b1513e ("PM: Restrict swap use to later in the suspend
sequence") changed two pm_restore_gfp_mask() calls in enter_state()
and hibernation_restore() into one pm_restore_gfp_mask() call in
dpm_resume_end(), but it put that call before the dpm_resume()
invocation which is too early (some swap-backing devices may not be
ready at that point).

Moreover, this code ordering change was not even mentioned in the
changelog of the commit mentioned above.

Address this by moving that call after the dpm_resume() one.

Fixes: 12ffc3b1513e ("PM: Restrict swap use to later in the suspend sequence")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/2797018.mvXUDI8C0e@rjwysocki.net
PM: Restrict swap use to later in the suspend sequence 2025-06-26T18:39:34+00:00 Mario Limonciello mario.limonciello@amd.com 2025-06-13T21:43:44+00:00 12ffc3b1513ebc1f11ae77d053948504a94a68a6 Currently swap is restricted before drivers have had a chance to do their prepare() PM callbacks. Restricting swap this early means that if a driver needs to evict some content from memory into sawp in it's prepare callback, it won't be able to. On AMD dGPUs this can lead to failed suspends under memory pressure situations as all VRAM must be evicted to system memory or swap. Move the swap restriction to right after all devices have had a chance to do the prepare() callback. If there is any problem with the sequence, restore swap in the appropriate dpm resume callbacks or error handling paths. Closes: https://github.com/ROCm/ROCK-Kernel-Driver/issues/174 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2362 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Tested-by: Nat Wittstock <nat@fardog.io> Tested-by: Lucian Langa <lucilanga@7pot.org> Link: https://patch.msgid.link/20250613214413.4127087-1-superm1@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Currently swap is restricted before drivers have had a chance to do
their prepare() PM callbacks. Restricting swap this early means that if
a driver needs to evict some content from memory into sawp in it's
prepare callback, it won't be able to.

On AMD dGPUs this can lead to failed suspends under memory pressure
situations as all VRAM must be evicted to system memory or swap.

Move the swap restriction to right after all devices have had a chance
to do the prepare() callback.  If there is any problem with the sequence,
restore swap in the appropriate dpm resume callbacks or error handling
paths.

Closes: https://github.com/ROCm/ROCK-Kernel-Driver/issues/174
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2362
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Tested-by: Nat Wittstock <nat@fardog.io>
Tested-by: Lucian Langa <lucilanga@7pot.org>
Link: https://patch.msgid.link/20250613214413.4127087-1-superm1@kernel.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
treewide, timers: Rename from_timer() to timer_container_of() 2025-06-08T07:07:37+00:00 Ingo Molnar mingo@kernel.org 2025-05-09T05:51:14+00:00 41cb08555c4164996d67c78b3bf1c658075b75f1 Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com 
Move this API to the canonical timer_*() namespace.

[ tglx: Redone against pre rc1 ]

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com
PM: sleep: Add locking to dpm_async_resume_children() 2025-06-03T20:14:03+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2025-06-03T16:21:57+00:00 8887abccf8aa16795f23ef3a3b25650cb8aa804c Commit 0cbef962ce1f ("PM: sleep: Resume children after resuming the parent") introduced a subtle concurrency issue that may lead to a kernel crash if system suspend is aborted and may also slow down asynchronous device resume otherwise. Namely, the initial list walks in dpm_noirq_resume_devices(), dpm_resume_early(), and dpm_resume() call dpm_clear_async_state() for every device and attempt to asynchronously resume it if it has no children (so it is a "root" device). The asynchronous resume of a root device triggers an attempt to asynchronously resume its children which may take place before calling dpm_clear_async_state() for them due to the lack of synchronization between dpm_async_resume_children() and the code calling dpm_clear_async_state(). If this happens, the dpm_clear_async_state() that comes in late, will clear power.work_in_progress for the given device after it has been set by __dpm_async(), so the suspend callback will be allowed to run once again for the same device during the same transition. This leads to a whole range of interesting breakage. Fortunately, if the suspend transition is not aborted, power.work_in_progress is set by it for all devices, so dpm_async_resume_children() will not schedule asynchronous resume for them until dpm_clear_async_state() clears that flag, but this means missing an opportunity to start the resume of those devices earlier. Address the above issue by adding dpm_list_mtx locking to dpm_async_resume_children(), so it will wait for the entire initial list walk and the invocation of dpm_clear_async_state() for all devices to be completed before scheduling any new asynchronous resume callbacks. Fixes: 0cbef962ce1f ("PM: sleep: Resume children after resuming the parent") Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4280 Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/13779172.uLZWGnKmhe@rjwysocki.net 
Commit 0cbef962ce1f ("PM: sleep: Resume children after resuming the
parent") introduced a subtle concurrency issue that may lead to a kernel
crash if system suspend is aborted and may also slow down asynchronous
device resume otherwise.

Namely, the initial list walks in dpm_noirq_resume_devices(),
dpm_resume_early(), and dpm_resume() call dpm_clear_async_state() for
every device and attempt to asynchronously resume it if it has no
children (so it is a "root" device).  The asynchronous resume of a
root device triggers an attempt to asynchronously resume its children
which may take place before calling dpm_clear_async_state() for them
due to the lack of synchronization between dpm_async_resume_children()
and the code calling dpm_clear_async_state().  If this happens, the
dpm_clear_async_state() that comes in late, will clear
power.work_in_progress for the given device after it has been set by
__dpm_async(), so the suspend callback will be allowed to run once
again for the same device during the same transition.  This leads to
a whole range of interesting breakage.

Fortunately, if the suspend transition is not aborted, power.work_in_progress
is set by it for all devices, so dpm_async_resume_children() will not
schedule asynchronous resume for them until dpm_clear_async_state()
clears that flag, but this means missing an opportunity to start the
resume of those devices earlier.

Address the above issue by adding dpm_list_mtx locking to
dpm_async_resume_children(), so it will wait for the entire initial
list walk and the invocation of dpm_clear_async_state() for all devices
to be completed before scheduling any new asynchronous resume callbacks.

Fixes: 0cbef962ce1f ("PM: sleep: Resume children after resuming the parent")
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4280
Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/13779172.uLZWGnKmhe@rjwysocki.net
PM: sleep: Fix power.is_suspended cleanup for direct-complete devices 2025-06-03T20:14:03+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2025-06-03T16:19:27+00:00 d46c4c839c20a599a0eb8d73708ce401f9c7d06d Commit 03f1444016b7 ("PM: sleep: Fix handling devices with direct_complete set on errors") caused power.is_suspended to be set for devices with power.direct_complete set, but it forgot to ensure the clearing of that flag for them in device_resume(), so power.is_suspended is still set for them during the next system suspend-resume cycle. If that cycle is aborted in dpm_suspend(), the subsequent invocation of dpm_resume() will trigger a device_resume() call for every device and because power.is_suspended is set for the devices in question, they will not be skipped by device_resume() as expected which causes scary error messages to be logged (as appropriate). To address this issue, move the clearing of power.is_suspended in device_resume() immediately after the power.is_suspended check so it will be always cleared for all devices processed by that function. Fixes: 03f1444016b7 ("PM: sleep: Fix handling devices with direct_complete set on errors") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4280 Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/4990586.GXAFRqVoOG@rjwysocki.net 
Commit 03f1444016b7 ("PM: sleep: Fix handling devices with direct_complete
set on errors") caused power.is_suspended to be set for devices with
power.direct_complete set, but it forgot to ensure the clearing of that
flag for them in device_resume(), so power.is_suspended is still set for
them during the next system suspend-resume cycle.

If that cycle is aborted in dpm_suspend(), the subsequent invocation of
dpm_resume() will trigger a device_resume() call for every device and
because power.is_suspended is set for the devices in question, they will
not be skipped by device_resume() as expected which causes scary error
messages to be logged (as appropriate).

To address this issue, move the clearing of power.is_suspended in
device_resume() immediately after the power.is_suspended check so it
will be always cleared for all devices processed by that function.

Fixes: 03f1444016b7 ("PM: sleep: Fix handling devices with direct_complete set on errors")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4280
Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/4990586.GXAFRqVoOG@rjwysocki.net
PM: sleep: Fix list splicing in device suspend error paths 2025-06-03T20:14:03+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2025-06-03T16:17:58+00:00 079e8889ad136930617278fbce44b42ef10af9e1 Commits aa7a9275ab81 ("PM: sleep: Suspend async parents after suspending children") and 443046d1ad66 ("PM: sleep: Make suspend of devices more asynchronous") added list splicing to the error paths of dpm_suspend(), dpm_suspend_late(), and dpm_noirq_suspend_devices(), but they should have used the list_splice_init() variant because the emptied list is used going forward in all of these cases. Replace list_splice() with list_splice_init() in the code in question as appropriate. Fixes: aa7a9275ab81 ("PM: sleep: Suspend async parents after suspending children") Fixes: 443046d1ad66 ("PM: sleep: Make suspend of devices more asynchronous") Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4280 Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/4659282.LvFx2qVVIh@rjwysocki.net 
Commits aa7a9275ab81 ("PM: sleep: Suspend async parents after suspending
children") and 443046d1ad66 ("PM: sleep: Make suspend of devices more
asynchronous") added list splicing to the error paths of dpm_suspend(),
dpm_suspend_late(), and dpm_noirq_suspend_devices(), but they should
have used the list_splice_init() variant because the emptied list is
used going forward in all of these cases.

Replace list_splice() with list_splice_init() in the code in question as
appropriate.

Fixes: aa7a9275ab81 ("PM: sleep: Suspend async parents after suspending children")
Fixes: 443046d1ad66 ("PM: sleep: Make suspend of devices more asynchronous")
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4280
Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/4659282.LvFx2qVVIh@rjwysocki.net
Merge tag 'driver-core-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core 2025-05-29T16:11:39+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-05-29T16:11:39+00:00 9d230d500b0e5f7be863e2bf2386be5f80dd18aa Pull driver core updates from Greg KH: "Here are the driver core / kernfs changes for 6.16-rc1. Not a huge number of changes this development cycle, here's the summary of what is included in here: - kernfs locking tweaks, pushing some global locks down into a per-fs image lock - rust driver core and pci device bindings added for new features. - sysfs const work for bin_attributes. The final churn of switching away from and removing the transitional struct members, "read_new", "write_new" and "bin_attrs_new" will come after the merge window to avoid unnecesary merge conflicts. - auxbus device creation helpers added - fauxbus fix for creating sysfs files after the probe completed properly - other tiny updates for driver core things. All of these have been in linux-next for over a week with no reported issues" * tag 'driver-core-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: kernfs: Relax constraint in draining guard Documentation: embargoed-hardware-issues.rst: Remove myself drivers: hv: fix up const issue with vmbus_chan_bin_attrs firmware_loader: use SHA-256 library API instead of crypto_shash API docs: debugfs: do not recommend debugfs_remove_recursive PM: wakeup: Do not expose 4 device wakeup source APIs kernfs: switch global kernfs_rename_lock to per-fs lock kernfs: switch global kernfs_idr_lock to per-fs lock driver core: auxiliary bus: Fix IS_ERR() vs NULL mixup in __devm_auxiliary_device_create() sysfs: constify attribute_group::bin_attrs sysfs: constify bin_attribute argument of bin_attribute::read/write() software node: Correct a OOB check in software_node_get_reference_args() devres: simplify devm_kstrdup() using devm_kmemdup() platform: replace magic number with macro PLATFORM_DEVID_NONE component: do not try to unbind unbound components driver core: auxiliary bus: add device creation helpers driver core: faux: Add sysfs groups after probing 
Pull driver core updates from Greg KH:
 "Here are the driver core / kernfs changes for 6.16-rc1.

  Not a huge number of changes this development cycle, here's the
  summary of what is included in here:

   - kernfs locking tweaks, pushing some global locks down into a per-fs
     image lock

   - rust driver core and pci device bindings added for new features.

   - sysfs const work for bin_attributes.

     The final churn of switching away from and removing the
     transitional struct members, "read_new", "write_new" and
     "bin_attrs_new" will come after the merge window to avoid
     unnecesary merge conflicts.

   - auxbus device creation helpers added

   - fauxbus fix for creating sysfs files after the probe completed
     properly

   - other tiny updates for driver core things.

  All of these have been in linux-next for over a week with no reported
  issues"

* tag 'driver-core-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core:
  kernfs: Relax constraint in draining guard
  Documentation: embargoed-hardware-issues.rst: Remove myself
  drivers: hv: fix up const issue with vmbus_chan_bin_attrs
  firmware_loader: use SHA-256 library API instead of crypto_shash API
  docs: debugfs: do not recommend debugfs_remove_recursive
  PM: wakeup: Do not expose 4 device wakeup source APIs
  kernfs: switch global kernfs_rename_lock to per-fs lock
  kernfs: switch global kernfs_idr_lock to per-fs lock
  driver core: auxiliary bus: Fix IS_ERR() vs NULL mixup in __devm_auxiliary_device_create()
  sysfs: constify attribute_group::bin_attrs
  sysfs: constify bin_attribute argument of bin_attribute::read/write()
  software node: Correct a OOB check in software_node_get_reference_args()
  devres: simplify devm_kstrdup() using devm_kmemdup()
  platform: replace magic number with macro PLATFORM_DEVID_NONE
  component: do not try to unbind unbound components
  driver core: auxiliary bus: add device creation helpers
  driver core: faux: Add sysfs groups after probing