On 13/03/18 09:55, Vivek Gautam wrote:
On Tue, Mar 13, 2018 at 3:10 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
On Tuesday, March 13, 2018 9:55:30 AM CET Vivek Gautam wrote:
The lists managing the device-links can be traversed to
find the link between two devices. The device_link_add() APIs
does traverse these lists to check if there's already a link
setup between the two devices.
So, add a new APIs, device_link_find(), to find an existing
device link between two devices - suppliers and consumers.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---

  * New patch added to this series.

  drivers/base/core.c    | 30 +++++++++++++++++++++++++++---
  include/linux/device.h |  2 ++
  2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 5847364f25d9..e8c9774e4ba2 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -144,6 +144,30 @@ static int device_reorder_to_tail(struct device *dev, void 
*not_used)
       return 0;
  }

+/**
+ * device_link_find - find any existing link between two devices.
+ * @consumer: Consumer end of the link.
+ * @supplier: Supplier end of the link.
+ *
+ * Returns pointer to the existing link between a supplier and
+ * and consumer devices, or NULL if no link exists.
+ */
+struct device_link *device_link_find(struct device *consumer,
+                                  struct device *supplier)
+{
+     struct device_link *link = NULL;
+
+     if (!consumer || !supplier)
+             return NULL;
+
+     list_for_each_entry(link, &supplier->links.consumers, s_node)
+             if (link->consumer == consumer)
+                     break;
+

Any mutual exclusion?

Or is the caller expected to take care of it?  And if so, then how?

I think it's better that we take care of lock here in the code rather
than depending
on the caller.
But i can't take device_links_write_lock() since device_link_add()
already takes that.

Well, the normal pattern is to break out the internal helper function as-is, then add a public wrapper which validates inputs, handles locking, etc., equivalently to existing caller(s). See what device_link_del() and others do, e.g.:

static struct device_link *__device_link_find(struct device *consumer,
                struct device *supplier)
{
        list_for_each_entry(link, &supplier->links.consumers, s_node)
                if (link->consumer == consumer)
                        return link;
        return NULL;
}

struct device_link *device_link_find(struct device *consumer,
                struct device *supplier)
{
        struct device_link *link;

        if (!consumer || !supplier)
                return NULL;

        device_links_write_lock();
        link = __device_link_find(consumer, supplier);  
        device_links_write_unlock();
        return link;
}

where device_link_add() would call __device_link_find() directly.

However, as Tomasz points out (and I hadn't really considered), if the only reasonable thing to with a link once you've found it is to delete it, then in terms of the public API it may well make more sense to just implement something like a device_link_remove() which does both in one go.

Robin.

Reply via email to