On Tue, Mar 07, 2023 at 11:09:01AM -0800, Saravana Kannan wrote:
On Tue, Mar 7, 2023 at 11:02 AM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
From: Saravana Kannan saravanak@google.com
[ Upstream commit 67cad5c67019c38126b749621665b6723d3ae7e6 ]
fw_devlink uses DL_FLAG_SYNC_STATE_ONLY device link flag for two purposes:
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.
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 saravanak@google.com Tested-by: Colin Foster colin.foster@in-advantage.com Tested-by: Sudeep Holla sudeep.holla@arm.com Tested-by: Douglas Anderson dianders@chromium.org Tested-by: Geert Uytterhoeven geert+renesas@glider.be Tested-by: Luca Weiss luca.weiss@fairphone.com # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-6-saravanak@google.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org
These fw_devlink patches weren't tested with 5.15. It's also an extensive refactor. So I'm a little worried if it'll be finicky and break things in a kernel that's a year old.
Unless someone specifically wants these patches in 5.15, I'd prefer we don't pick it up in 5.15.
Good point, I'll go drop this from the 5.15.y queue.
thanks,
greg k-h