linux-stable.git/drivers/base, branch v6.2.3

genirq/msi, platform-msi: Ensure that MSI descriptors are unreferenced

2023-03-10T08:29:48+00:00

commit 0fb7fb713461e44b12e72c292bf90ee300f40710 upstream.

Miquel reported a warning in the MSI core which is triggered when
interrupts are freed via platform_msi_device_domain_free().

This code got reworked to use core functions for freeing the MSI
descriptors, but nothing took care to clear the msi_desc->irq entry, which
then triggers the warning in msi_free_msi_desc() which uses desc->irq to
validate that the descriptor has been torn down. The same issue exists in
msi_domain_populate_irqs().

Up to the point that msi_free_msi_descs() grew a warning for this case,
this went un-noticed.

Provide the counterpart of msi_domain_populate_irqs() and invoke it in
platform_msi_device_domain_free() before freeing the interrupts and MSI
descriptors and also in the error path of msi_domain_populate_irqs().

Fixes: 2f2940d16823 ("genirq/msi: Remove filter from msi_free_descs_free_range()")
Reported-by: Miquel Raynal 
Signed-off-by: Thomas Gleixner 
Tested-by: Miquel Raynal 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/87mt4wkwnv.ffs@tglx
Signed-off-by: Greg Kroah-Hartman

driver core: fw_devlink: Avoid spurious error message

2023-03-10T08:29:22+00:00

[ Upstream commit 6309872413f14f3d58c13ae4dc85b1a7004b4193 ]

fw_devlink can sometimes try to create a device link with the consumer
and supplier as the same device. These attempts will fail (correctly),
but are harmless. So, avoid printing an error for these cases. Also, add
more detail to the error message.

Fixes: 3fb16866b51d ("driver core: fw_devlink: Make cycle detection more robust")
Reported-by: Vladimir Oltean 
Reported-by: Dmitry Baryshkov 
Signed-off-by: Saravana Kannan 
Link: https://lore.kernel.org/r/20230225064148.274376-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

PM: domains: fix memory leak with using debugfs_lookup()

2023-03-10T08:29:12+00:00

[ Upstream commit 0b6200e1e9f53dabdc30d0f6c51af9a5f664d32b ]

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time.  To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.

Signed-off-by: Greg Kroah-Hartman 
Reviewed-by: Ulf Hansson 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

driver core: fw_devlink: Make cycle detection more robust

2023-03-10T08:28:55+00:00

[ Upstream commit 3fb16866b51ded6c016b664caad53f8d4fd9dc56 ]

fw_devlink could only detect a single and simple cycle because it relied
mainly on device link cycle detection code that only checked for cycles
between devices. The expectation was that the firmware wouldn't have
complicated cycles and multiple cycles between devices. That expectation
has been proven to be wrong.

For example, fw_devlink could handle:

+-+        +-+
|A+------> |B+
+-+        +++
 ^          |
 |          |
 +----------+

But it couldn't handle even something as "simple" as:

 +---------------------+
 |                     |
 v                     |
+-+        +-+        +++
|A+------> |B+------> |C|
+-+        +++        +-+
 ^          |
 |          |
 +----------+

But firmware has even more complicated cycles like:

    +---------------------+
    |                     |
    v                     |
   +-+       +---+       +++
+--+A+------>| B +-----> |C|<--+
|  +-+       ++--+       +++   |
|   ^         | ^         |    |
|   |         | |         |    |
|   +---------+ +---------+    |
|                              |
+------------------------------+

And this is without including parent child dependencies or nodes in the
cycle that are just firmware nodes that'll never have a struct device
created for them.

The proper way to treat these devices it to not force any probe ordering
between them, while still enforce dependencies between node in the
cycles (A, B and C) and their consumers.

So this patch goes all out and just deals with all types of cycles. It
does this by:

1. Following dependencies across device links, parent-child and fwnode
   links.
2. When it find cycles, it mark the device links and fwnode links as
   such instead of just deleting them or making the indistinguishable
   from proxy SYNC_STATE_ONLY device links.

This way, when new nodes get added, we can immediately find and mark any
new cycles whether the new node is a device or firmware node.

Fixes: 2de9d8e0d2fe ("driver core: fw_devlink: Improve handling of cyclic dependencies")
Signed-off-by: Saravana Kannan 
Tested-by: Colin Foster 
Tested-by: Sudeep Holla 
Tested-by: Douglas Anderson 
Tested-by: Geert Uytterhoeven 
Tested-by: Luca Weiss  # qcom/sm7225-fairphone-fp4
Link: https://lore.kernel.org/r/20230207014207.1678715-9-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

driver core: fw_devlink: Improve check for fwnode with no device/driver

2023-03-10T08:28:55+00:00

[ Upstream commit 411c0d58ca6faa9bc4b9f5382118a31c7bb92a6f ]

fw_devlink shouldn't defer the probe of a device to wait on a supplier
that'll never have a struct device or will never be probed by a driver.
We currently check if a supplier falls into this category, but don't
check its ancestors. We need to check the ancestors too because if the
ancestor will never probe, then the supplier will never probe either.

Signed-off-by: Saravana Kannan 
Tested-by: Colin Foster 
Tested-by: Sudeep Holla 
Tested-by: Douglas Anderson 
Tested-by: Geert Uytterhoeven 
Tested-by: Luca Weiss  # qcom/sm7225-fairphone-fp4
Link: https://lore.kernel.org/r/20230207014207.1678715-3-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman 
Stable-dep-of: 3fb16866b51d ("driver core: fw_devlink: Make cycle detection more robust")
Signed-off-by: Sasha Levin

driver core: fw_devlink: Consolidate device link flag computation

2023-03-10T08:28:55+00:00

[ Upstream commit cd115c0409f283edde94bd5a9a42dc42bee0aba8 ]

Consolidate the code that computes the flags to be used when creating a
device link from a fwnode link.

Fixes: 2de9d8e0d2fe ("driver core: fw_devlink: Improve handling of cyclic dependencies")
Signed-off-by: Saravana Kannan 
Tested-by: Colin Foster 
Tested-by: Sudeep Holla 
Tested-by: Douglas Anderson 
Tested-by: Geert Uytterhoeven 
Tested-by: Luca Weiss  # qcom/sm7225-fairphone-fp4
Link: https://lore.kernel.org/r/20230207014207.1678715-8-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

driver core: fw_devlink: Allow marking a fwnode link as being part of a cycle

2023-03-10T08:28:55+00:00

[ Upstream commit 6a6dfdf8b3ff337be5a447e9f4e71969f18370ad ]

To improve detection and handling of dependency cycles, we need to be
able to mark fwnode links as being part of cycles. fwnode links marked
as being part of a cycle should not block their consumers from probing.

Fixes: 2de9d8e0d2fe ("driver core: fw_devlink: Improve handling of cyclic dependencies")
Signed-off-by: Saravana Kannan 
Tested-by: Colin Foster 
Tested-by: Sudeep Holla 
Tested-by: Douglas Anderson 
Tested-by: Geert Uytterhoeven 
Tested-by: Luca Weiss  # qcom/sm7225-fairphone-fp4
Link: https://lore.kernel.org/r/20230207014207.1678715-7-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

driver core: fw_devlink: Don't purge child fwnode's consumer links

2023-03-10T08:28:55+00:00

[ Upstream commit 3a2dbc510c437ca392516b0105bad8e7970e6614 ]

When a device X is bound successfully to a driver, if it has a child
firmware node Y that doesn't have a struct device created by then, we
delete fwnode links where the child firmware node Y is the supplier. We
did this to avoid blocking the consumers of the child firmware node Y
from deferring probe indefinitely.

While that a step in the right direction, it's better to make the
consumers of the child firmware node Y to be consumers of the device X
because device X is probably implementing whatever functionality is
represented by child firmware node Y. By doing this, we capture the
device dependencies more accurately and ensure better
probe/suspend/resume ordering.

Signed-off-by: Saravana Kannan 
Tested-by: Colin Foster 
Tested-by: Sudeep Holla 
Tested-by: Douglas Anderson 
Tested-by: Geert Uytterhoeven 
Tested-by: Luca Weiss  # qcom/sm7225-fairphone-fp4
Link: https://lore.kernel.org/r/20230207014207.1678715-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman 
Stable-dep-of: 6a6dfdf8b3ff ("driver core: fw_devlink: Allow marking a fwnode link as being part of a cycle")
Signed-off-by: Sasha Levin

driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links

2023-03-10T08:28:55+00:00

[ Upstream commit 67cad5c67019c38126b749621665b6723d3ae7e6 ]

fw_devlink uses DL_FLAG_SYNC_STATE_ONLY device link flag for two
purposes:

1. To allow a parent device to proxy its child device's dependency on a
   supplier so that the supplier doesn't get its sync_state() callback
   before the child device/consumer can be added and probed. In this
   usage scenario, we need to ignore cycles for ensure correctness of
   sync_state() callbacks.

2. When there are dependency cycles in firmware, we don't know which of
   those dependencies are valid. So, we have to ignore them all wrt
   probe ordering while still making sure the sync_state() callbacks
   come correctly.

However, when detecting dependency cycles, there can be multiple
dependency cycles between two devices that we need to detect. For
example:

A -> B -> A and A -> C -> B -> A.

To detect multiple cycles correct, we need to be able to differentiate
DL_FLAG_SYNC_STATE_ONLY device links used for (1) vs (2) above.

To allow this differentiation, add a DL_FLAG_CYCLE that can be use to
mark use case (2). We can then use the DL_FLAG_CYCLE to decide which
DL_FLAG_SYNC_STATE_ONLY device links to follow when looking for
dependency cycles.

Fixes: 2de9d8e0d2fe ("driver core: fw_devlink: Improve handling of cyclic dependencies")
Signed-off-by: Saravana Kannan 
Tested-by: Colin Foster 
Tested-by: Sudeep Holla 
Tested-by: Douglas Anderson 
Tested-by: Geert Uytterhoeven 
Tested-by: Luca Weiss  # qcom/sm7225-fairphone-fp4
Link: https://lore.kernel.org/r/20230207014207.1678715-6-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

drivers: base: transport_class: fix resource leak when transport_add_device() fails

2023-03-10T08:28:52+00:00

[ Upstream commit e5da06b27ff5a148e42265c8e306670a9d913969 ]

The normal call sequence of using transport class is:

Add path:
transport_setup_device()
  transport_setup_classdev()  // call sas_host_setup() here
transport_add_device()	      // if fails, need call transport_destroy_device()
transport_configure_device()

Remove path:
transport_remove_device()
  transport_remove_classdev  // call sas_host_remove() here
transport_destroy_device()

If transport_add_device() fails, need call transport_destroy_device()
to free memory, but in this case, ->remove() is not called, and the
resources allocated in ->setup() are leaked. So fix these leaks by
calling ->remove() in transport_add_class_device() if it returns error.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang 
Link: https://lore.kernel.org/r/20221115031638.3816551-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin