From: Saravana Kannan <saravanak@google.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>
Cc: Saravana Kannan <saravanak@google.com>,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
John Stultz <john.stultz@linaro.org>,
kernel-team@android.com
Subject: [PATCH v2 2/2] of: property: Improve cycle detection when one of the devices is never added
Date: Tue, 9 Jun 2020 18:19:34 -0700 [thread overview]
Message-ID: <20200610011934.49795-3-saravanak@google.com> (raw)
In-Reply-To: <20200610011934.49795-1-saravanak@google.com>
Consider this example where -> means LHS device is a consumer of RHS
device and indentation represents "child of" of the previous device.
Device A -> Device C
Device B -> Device A
Device C
Without this commit:
1. Device A is added.
2. Device A is added to waiting for supplier list (Device C)
3. Device B is added
4. Device B is linked as a consumer to Device A
5. Device A doesn't probe because it's waiting for Device C to be added.
6. Device B doesn't probe because Device A hasn't probed.
7. Device C will never be added because it's parent hasn't probed.
So, Device A, B and C will be in a probe/add deadlock.
This commit detects this scenario and stops trying to create a device
link between Device A and Device C since doing so would create the
following cycle:
Device A -> Devic C -(parent)-> Device B -> Device A.
With this commit:
1. Device A is added.
3. Device B is added
4. Device B is linked as a consumer to Device A
5. Device A probes.
6. Device B probes because Device A has probed.
7. Device C is added and probed.
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
drivers/of/property.c | 62 ++++++++++++++++++++++++++++++++++++++-----
1 file changed, 56 insertions(+), 6 deletions(-)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 1f2086f4e7ce..ef09e4372ce8 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1014,6 +1014,30 @@ static bool of_is_ancestor_of(struct device_node *test_ancestor,
return false;
}
+/**
+ * of_get_next_parent_dev - Add device link to supplier from supplier phandle
+ * @np: device tree node
+ *
+ * Given a device tree node (@np), this function finds its closest ancestor
+ * device tree node that has a corresponding struct device.
+ *
+ * The caller of this function is expected to call put_device() on the returned
+ * device when they are done.
+ */
+static struct device *of_get_next_parent_dev(struct device_node *np)
+{
+ struct device *dev = NULL;
+
+ of_node_get(np);
+ do {
+ np = of_get_next_parent(np);
+ if (np)
+ dev = get_dev_from_fwnode(&np->fwnode);
+ } while (np && !dev);
+ of_node_put(np);
+ return dev;
+}
+
/**
* of_link_to_phandle - Add device link to supplier from supplier phandle
* @dev: consumer device
@@ -1035,10 +1059,9 @@ static bool of_is_ancestor_of(struct device_node *test_ancestor,
static int of_link_to_phandle(struct device *dev, struct device_node *sup_np,
u32 dl_flags)
{
- struct device *sup_dev;
+ struct device *sup_dev, *sup_par_dev;
int ret = 0;
struct device_node *tmp_np = sup_np;
- int is_populated;
of_node_get(sup_np);
/*
@@ -1075,16 +1098,43 @@ static int of_link_to_phandle(struct device *dev, struct device_node *sup_np,
return -EINVAL;
}
sup_dev = get_dev_from_fwnode(&sup_np->fwnode);
- is_populated = of_node_check_flag(sup_np, OF_POPULATED);
- of_node_put(sup_np);
- if (!sup_dev && is_populated) {
+ if (!sup_dev && of_node_check_flag(sup_np, OF_POPULATED)) {
/* Early device without struct device. */
dev_dbg(dev, "Not linking to %pOFP - No struct device\n",
sup_np);
+ of_node_put(sup_np);
return -ENODEV;
} else if (!sup_dev) {
- return -EAGAIN;
+ /*
+ * DL_FLAG_SYNC_STATE_ONLY doesn't block probing and supports
+ * cycles. So cycle detection isn't necessary and shouldn't be
+ * done.
+ */
+ if (dl_flags & DL_FLAG_SYNC_STATE_ONLY) {
+ of_node_put(sup_np);
+ return -EAGAIN;
+ }
+
+ sup_par_dev = of_get_next_parent_dev(sup_np);
+
+ if (sup_par_dev && device_is_dependent(dev, sup_par_dev)) {
+ /* Cyclic dependency detected, don't try to link */
+ dev_dbg(dev, "Not linking to %pOFP - cycle detected\n",
+ sup_np);
+ ret = -EINVAL;
+ } else {
+ /*
+ * Can't check for cycles or no cycles. So let's try
+ * again later.
+ */
+ ret = -EAGAIN;
+ }
+
+ of_node_put(sup_np);
+ put_device(sup_par_dev);
+ return ret;
}
+ of_node_put(sup_np);
if (!device_link_add(dev, sup_dev, dl_flags))
ret = -EINVAL;
put_device(sup_dev);
--
2.27.0.278.ge193c7cf3a9-goog
next prev parent reply other threads:[~2020-06-10 1:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 1:19 [PATCH v2 0/2] fw_devlink: Improve cycle detection in DT Saravana Kannan
2020-06-10 1:19 ` [PATCH v2 1/2] driver core: Add device_is_dependent() to linux/device.h Saravana Kannan
2020-06-10 1:19 ` Saravana Kannan [this message]
2020-06-17 22:12 ` [PATCH v2 2/2] of: property: Improve cycle detection when one of the devices is never added Rob Herring
2020-06-18 1:13 ` Saravana Kannan
2020-06-10 4:47 ` [PATCH v2 0/2] fw_devlink: Improve cycle detection in DT John Stultz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200610011934.49795-3-saravanak@google.com \
--to=saravanak@google.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=john.stultz@linaro.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).