linux-stable.git/drivers/base/core.c, branch v6.1.2

driver core: use IS_ERR_OR_NULL() helper in device_create_groups_vargs()

2022-09-24T13:00:38+00:00

Use IS_ERR_OR_NULL() helper in device_create_groups_vargs() to simplify code
and improve readiblity. No functional change.

Signed-off-by: Yang Yingliang 
Link: https://lore.kernel.org/r/20220914140753.3799982-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman

Merge 1707c39ae309 ("Merge tag 'driver-core-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core") driver-core-next

2022-09-24T11:32:01+00:00

This merges the driver core changes in 6.0-rc7 into driver-core-next as
they are needed here as well for testing.

Signed-off-by: Greg Kroah-Hartman

Revert "driver core: Set fw_devlink.strict=1 by default"

2022-09-15T10:44:56+00:00

This reverts commit 71066545b48e4259f89481199a0bbc7c35457738.

It causes boot problems on some systems, so revert it for now until it
is worked out.

Cc: Geert Uytterhoeven 
Cc: Saravana Kannan 
Fixes: 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
Reported-by: Olof Johansson 
Link: https://lore.kernel.org/r/CAOesGMjQHhTUMBGHQcME4JBkZCof2NEQ4gaM1GWFgH40+LN9AQ@mail.gmail.com
Signed-off-by: Greg Kroah-Hartman

drivers: base: Print error code on synthetic uevent failure

2022-09-01T16:15:50+00:00

If we're going to log the failure, we might as well log the return code
too.

Signed-off-by: Brian Norris 
Link: https://lore.kernel.org/r/20220824165213.1.Ifdb98af3d0c23708a11d8d5ae5697bdb7e96a3cc@changeid
Signed-off-by: Greg Kroah-Hartman

Merge tag 'driver-core-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2022-08-04T18:31:20+00:00

Pull driver core / kernfs updates from Greg KH:
 "Here is the set of driver core and kernfs changes for 6.0-rc1.

  The "biggest" thing in here is some scalability improvements for
  kernfs for large systems. Other than that, included in here are:

   - arch topology and cache info changes that have been reviewed and
     discussed a lot.

   - potential error path cleanup fixes

   - deferred driver probe cleanups

   - firmware loader cleanups and tweaks

   - documentation updates

   - other small things

  All of these have been in the linux-next tree for a while with no
  reported problems"

* tag 'driver-core-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (63 commits)
  docs: embargoed-hardware-issues: fix invalid AMD contact email
  firmware_loader: Replace kmap() with kmap_local_page()
  sysfs docs: ABI: Fix typo in comment
  kobject: fix Kconfig.debug "its" grammar
  kernfs: Fix typo 'the the' in comment
  docs: driver-api: firmware: add driver firmware guidelines. (v3)
  arch_topology: Fix cache attributes detection in the CPU hotplug path
  ACPI: PPTT: Leave the table mapped for the runtime usage
  cacheinfo: Use atomic allocation for percpu cache attributes
  drivers/base: fix userspace break from using bin_attributes for cpumap and cpulist
  MAINTAINERS: Change mentions of mpm to olivia
  docs: ABI: sysfs-devices-soc: Update Lee Jones' email address
  docs: ABI: sysfs-class-pwm: Update Lee Jones' email address
  Documentation/process: Add embargoed HW contact for LLVM
  Revert "kernfs: Change kernfs_notify_list to llist."
  ACPI: Remove the unused find_acpi_cpu_cache_topology()
  arch_topology: Warn that topology for nested clusters is not supported
  arch_topology: Add support for parsing sockets in /cpu-map
  arch_topology: Set cluster identifier in each core/thread from /cpu-map
  arch_topology: Limit span of cpu_clustergroup_mask()
  ...

PM: runtime: Fix supplier device management during consumer probe

2022-07-01T19:04:15+00:00

Because pm_runtime_get_suppliers() bumps up the rpm_active counter
of each device link to a supplier of the given device in addition
to bumping up the supplier's PM-runtime usage counter, a runtime
suspend of the consumer device may case the latter to go down to 0
when pm_runtime_put_suppliers() is running on a remote CPU.  If that
happens after pm_runtime_put_suppliers() has released power.lock for
the consumer device, and a runtime resume of that device takes place
immediately after it, before pm_runtime_put() is called for the
supplier, that pm_runtime_put() call may cause the supplier to be
suspended even though the consumer is active.

To prevent that from happening, modify pm_runtime_get_suppliers() to
call pm_runtime_get_sync() for the given device's suppliers without
touching the rpm_active counters of the involved device links
Accordingly, modify pm_runtime_put_suppliers() to call pm_runtime_put()
for the given device's suppliers without looking at the rpm_active
counters of the device links at hand.  [This is analogous to what
happened before commit 4c06c4e6cf63 ("driver core: Fix possible
supplier PM-usage counter imbalance").]

Since pm_runtime_get_suppliers() sets supplier_preactivated for each
device link where the supplier's PM-runtime usage counter has been
incremented and pm_runtime_put_suppliers() calls pm_runtime_put() for
the suppliers whose device links have supplier_preactivated set, the
PM-runtime usage counter is balanced for each supplier and this is
independent of the runtime suspend and resume of the consumer device.

However, in case a device link with DL_FLAG_PM_RUNTIME set is dropped
during the consumer device probe, so pm_runtime_get_suppliers() bumps
up the supplier's PM-runtime usage counter, but it cannot be dropped by
pm_runtime_put_suppliers(), make device_link_release_fn() take care of
that.

Fixes: 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance")
Reported-by: Peter Wang 
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Peter Wang 
Cc: 5.1+  # 5.1+

PM: runtime: Redefine pm_runtime_release_supplier()

2022-07-01T19:04:02+00:00

Instead of passing an extra bool argument to pm_runtime_release_supplier(),
make its callers take care of triggering a runtime-suspend of the
supplier device as needed.

No expected functional impact.

Suggested-by: Greg Kroah-Hartman 
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Greg Kroah-Hartman 
Cc: 5.1+  # 5.1+

driver core: fw_devlink: Allow firmware to mark devices as best effort

2022-06-27T14:52:25+00:00

When firmware sets the FWNODE_FLAG_BEST_EFFORT flag for a fwnode,
fw_devlink will do a best effort ordering for that device where it'll
only enforce the probe/suspend/resume ordering of that device with
suppliers that have drivers. The driver of that device can then decide
if it wants to defer probe or probe without the suppliers.

This will be useful for avoid probe delays of the console device that
were caused by commit 71066545b48e ("driver core: Set
fw_devlink.strict=1 by default").

Fixes: 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
Reported-by: Sascha Hauer 
Reported-by: Peng Fan 
Tested-by: Peng Fan 
Signed-off-by: Saravana Kannan 
Link: https://lore.kernel.org/r/20220623080344.783549-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman

driver core: Introduce device_find_any_child() helper

2022-06-10T14:01:55+00:00

There are several places in the kernel where this kind of functionality is
being used. Provide a generic helper for such cases.

Reviewed-by: Rafael J. Wysocki 
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220610120219.18988-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

driver core: Set fw_devlink.strict=1 by default

2022-06-10T13:57:54+00:00

Now that deferred_probe_timeout is non-zero by default, fw_devlink will
never permanently block the probing of devices. It'll try its best to
probe the devices in the right order and then finally let devices probe
even if their suppliers don't have any drivers.

Tested-by: Geert Uytterhoeven 
Signed-off-by: Saravana Kannan 
Link: https://lore.kernel.org/r/20220601070707.3946847-8-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman