linux.git/drivers/base, branch v4.14.249

PM: base: power: don't try to use non-existing RTC for storing data

2021-09-22T09:45:33+00:00

commit 0560204b360a332c321124dbc5cdfd3364533a74 upstream.

If there is no legacy RTC device, don't try to use it for storing trace
data across suspend/resume.

Cc: 
Signed-off-by: Juergen Gross 
Reviewed-by: Rafael J. Wysocki 
Link: https://lore.kernel.org/r/20210903084937.19392-2-jgross@suse.com
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman

regmap: fix the offset of register error log

2021-09-22T09:45:17+00:00

[ Upstream commit 1852f5ed358147095297a09cc3c6f160208a676d ]

This patch fixes the offset of register error log
by using regmap_get_offset().

Signed-off-by: Jeongtae Park 
Link: https://lore.kernel.org/r/20210701142630.44936-1-jeongtae.park@gmail.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

opp: remove WARN when no valid OPPs remain

2021-09-03T07:56:25+00:00

[ Upstream commit 335ffab3ef864539e814b9a2903b0ae420c1c067 ]

This WARN can be triggered per-core and the stack trace is not useful.
Replace it with plain dev_err(). Fix a comment while at it.

Signed-off-by: Michał Mirosław 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

PCI/MSI: Protect msi_desc::masked for multi-MSI

2021-08-26T12:37:04+00:00

commit 77e89afc25f30abd56e76a809ee2884d7c1b63ce upstream.

Multi-MSI uses a single MSI descriptor and there is a single mask register
when the device supports per vector masking. To avoid reading back the mask
register the value is cached in the MSI descriptor and updates are done by
clearing and setting bits in the cache and writing it to the device.

But nothing protects msi_desc::masked and the mask register from being
modified concurrently on two different CPUs for two different Linux
interrupts which belong to the same multi-MSI descriptor.

Add a lock to struct device and protect any operation on the mask and the
mask register with it.

This makes the update of msi_desc::masked unconditional, but there is no
place which requires a modification of the hardware register without
updating the masked cache.

msi_mask_irq() is now an empty wrapper which will be cleaned up in follow
up changes.

The problem goes way back to the initial support of multi-MSI, but picking
the commit which introduced the mask cache is a valid cut off point
(2.6.30).

Fixes: f2440d9acbe8 ("PCI MSI: Refactor interrupt masking code")
Signed-off-by: Thomas Gleixner 
Tested-by: Marc Zyngier 
Reviewed-by: Marc Zyngier 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.726833414@linutronix.de
Signed-off-by: Greg Kroah-Hartman

Revert "PM: runtime: Update device status before letting suppliers suspend"

2021-03-24T10:04:55+00:00

commit 0cab893f409c53634d0d818fa414641cbcdb0dab upstream.

Revert commit 44cc89f76464 ("PM: runtime: Update device status
before letting suppliers suspend") that introduced a race condition
into __rpm_callback() which allowed a concurrent rpm_resume() to
run and resume the device prematurely after its status had been
changed to RPM_SUSPENDED by __rpm_callback().

Fixes: 44cc89f76464 ("PM: runtime: Update device status before letting suppliers suspend")
Link: https://lore.kernel.org/linux-pm/24dfb6fc-5d54-6ee2-9195-26428b7ecf8a@intel.com/
Reported-by: Adrian Hunter 
Cc: 4.10+  # 4.10+
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

PM: runtime: Update device status before letting suppliers suspend

2021-03-11T12:51:04+00:00

commit 44cc89f764646b2f1f2ea5d1a08b230131707851 upstream.

Because the PM-runtime status of the device is not updated in
__rpm_callback(), attempts to suspend the suppliers of the given
device triggered by rpm_put_suppliers() called by it may fail.

Fix this by making __rpm_callback() update the device's status to
RPM_SUSPENDED before calling rpm_put_suppliers() if the current
status of the device is RPM_SUSPENDING and the callback just invoked
by it has returned 0 (success).

While at it, modify the code in __rpm_callback() to always check
the device's PM-runtime status under its PM lock.

Link: https://lore.kernel.org/linux-pm/CAPDyKFqm06KDw_p8WXsM4dijDbho4bb6T4k50UqqvR1_COsp8g@mail.gmail.com/
Fixes: 21d5c57b3726 ("PM / runtime: Use device links")
Reported-by: Elaine Zhang 
Diagnosed-by: Ulf Hansson 
Signed-off-by: Rafael J. Wysocki 
Tested-by: Elaine Zhang 
Reviewed-by: Ulf Hansson 
Cc: 4.10+  # 4.10+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

driver core: Extend device_is_dependent()

2021-02-07T13:47:40+00:00

commit 3d1cf435e201d1fd63e4346b141881aed086effd upstream

If the device passed as the target (second argument) to
device_is_dependent() is not completely registered (that is, it has
been initialized, but not added yet), but the parent pointer of it
is set, it may be missing from the list of the parent's children
and device_for_each_child() called by device_is_dependent() cannot
be relied on to catch that dependency.

For this reason, modify device_is_dependent() to check the ancestors
of the target device by following its parent pointer in addition to
the device_for_each_child() walk.

Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support")
Reported-by: Stephan Gerhold 
Tested-by: Stephan Gerhold 
Reviewed-by: Saravana Kannan 
Signed-off-by: Rafael J. Wysocki 
Link: https://lore.kernel.org/r/17705994.d592GUb2YH@kreacher
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sudip Mukherjee 
Signed-off-by: Greg Kroah-Hartman

base: core: Remove WARN_ON from link dependencies check

2021-02-07T13:47:40+00:00

commit e16f4f3e0b7daecd48d4f944ab4147c1a6cb16a8 upstream

In some cases the link between between customer and supplier
already exist, for example when a device use its parent as a supplier.
Do not warn about already existing dependencies because device_link_add()
takes care of this case.

Link: http://lkml.kernel.org/r/20180709111753eucas1p1f32e66fb2f7ea3216097cd72a132355d~-rzycA5Rg0378203782eucas1p1C@eucas1p1.samsung.com

Reported-by: Marek Szyprowski 
Reviewed-by: Mark Brown 
Signed-off-by: Benjamin Gaignard 
Reviewed-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sudip Mukherjee 
Signed-off-by: Greg Kroah-Hartman

Revert "device property: Keep secondary firmware node secondary by type"

2021-01-12T19:09:14+00:00

commit 47f4469970d8861bc06d2d4d45ac8200ff07c693 upstream.

While commit d5dcce0c414f ("device property: Keep secondary firmware
node secondary by type") describes everything correct in its commit
message, the change it made does the opposite and original commit
c15e1bdda436 ("device property: Fix the secondary firmware node handling
in set_primary_fwnode()") was fully correct.

Revert the former one here and improve documentation in the next patch.

Fixes: d5dcce0c414f ("device property: Keep secondary firmware node secondary by type")
Signed-off-by: Bard Liao 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Heikki Krogerus 
Cc: 5.10+  # 5.10+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM: runtime: Resume the device earlier in __device_release_driver()

2020-11-10T09:29:07+00:00

commit 9226c504e364158a17a68ff1fe9d67d266922f50 upstream.

Since the device is resumed from runtime-suspend in
__device_release_driver() anyway, it is better to do that before
looking for busy managed device links from it to consumers, because
if there are any, device_links_unbind_consumers() will be called
and it will cause the consumer devices' drivers to unbind, so the
consumer devices will be runtime-resumed.  In turn, resuming each
consumer device will cause the supplier to be resumed and when the
runtime PM references from the given consumer to it are dropped, it
may be suspended.  Then, the runtime-resume of the next consumer
will cause the supplier to resume again and so on.

Update the code accordingly.

Signed-off-by: Rafael J. Wysocki 
Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support")
Cc: All applicable  # All applicable
Tested-by: Xiang Chen 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman