Messages in this thread | | | Subject | Re: [PATCH v9 1/5] driver core: Find an existing link between two devices | From | Robin Murphy <> | Date | Tue, 13 Mar 2018 12:49:37 +0000 |
| |
On 13/03/18 09:55, Vivek Gautam wrote: > On Tue, Mar 13, 2018 at 3:10 PM, Rafael J. Wysocki <rjw@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.gautam@codeaurora.org> >>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> >>> Cc: Greg Kroah-Hartman <gregkh@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.
| |