Received: by 10.213.65.68 with SMTP id h4csp953003imn; Wed, 14 Mar 2018 05:24:42 -0700 (PDT) X-Google-Smtp-Source: AG47ELuvjuey1yrnUvK0ubimWTlBmfx1l2Pfm/DoIwz9aaDHpbfKMPmY2XciI0f8EbsD2ZYvPM6A X-Received: by 10.98.17.86 with SMTP id z83mr4093768pfi.207.1521030282930; Wed, 14 Mar 2018 05:24:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521030282; cv=none; d=google.com; s=arc-20160816; b=UrvYDXeBGT91HEYYPILl5XKvEThKBWm/3/XzKUincq0OCwFjkMi9/NcegQFfCqLYcE N2HDQ19dIcn5ciXCHfhXn9VvKjEf+K3vMvJuuJz0zvOn+KsncPPzDo8M8sMuaULe+Du6 qA4D/HImDIa1nIyE9avdc67zycaQajydf52hY0dzShc1ztDjT0K9cYYX8P1FfYqICUkv AIbvYHmcJ2IFUa8alBCnkJeuPOcMkFL0UGVfb0jqPycBo+8PlnKR0wGKcvXv/4CBcOmH jp98JWca6JvVWs2ILYLfHCY6lrJ7KqOxf/CPkeczwrs5hIRXrmEq+Tx+o2R84YfN2Oxu WhVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=L8c/dMpmms8975xyJXkag4epgiZND1RVlFaKIMdzqeM=; b=yb2qg+3LmhTGe2jwgbVCrT6pr2c3cXyHtw/MLp1aQBP6iVqNvhfHvMPpyB9TbGdCWz nossoQ2DXLUG5fJHLqapJEHwbCwgieD54qeeuh+gnoPHY9CxN0dF8edrSZte4OJACo4A rCHB6bSYwYaOypGzG/uxgiMNLKnE3ePUposx3tYaryULyKIFW86eNg1d2mJ1esF+zPxi WRpMWn36tA5N0LMfBy2EBUGdmxBtzAlbmXa5L8IdDxtWVoZl8qXq1zlu41OQBL3LT4zP WLr3EM1gWy1FAUMFEVeHCX7F9ZfnXhFhfD7eOwi7sjGj9/g3Fres+GD9fDWY2z2/Y+WK XMxg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f1-v6si1902044plb.73.2018.03.14.05.24.28; Wed, 14 Mar 2018 05:24:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751886AbeCNMXd (ORCPT + 99 others); Wed, 14 Mar 2018 08:23:33 -0400 Received: from bmailout2.hostsharing.net ([83.223.90.240]:51967 "EHLO bmailout2.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751289AbeCNMX3 (ORCPT ); Wed, 14 Mar 2018 08:23:29 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id B997F2800BC36; Wed, 14 Mar 2018 13:23:26 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 482D2195D3; Wed, 14 Mar 2018 13:23:26 +0100 (CET) Date: Wed, 14 Mar 2018 13:23:26 +0100 From: Lukas Wunner To: "Rafael J. Wysocki" Cc: Tomasz Figa , Vivek Gautam , Joerg Roedel , Rob Herring , Robin Murphy , "open list:IOMMU DRIVERS" , devicetree@vger.kernel.org, Linux Kernel Mailing List , Mark Rutland , Will Deacon , Rob Clark , Sricharan R , Marek Szyprowski , Archit Taneja , linux-arm-msm , Greg Kroah-Hartman Subject: Re: [PATCH v9 1/5] driver core: Find an existing link between two devices Message-ID: <20180314122326.GA19651@wunner.de> References: <20180313085534.11650-1-vivek.gautam@codeaurora.org> <2217404.A2W3Iek6du@aspire.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2217404.A2W3Iek6du@aspire.rjw.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 14, 2018 at 12:12:05PM +0100, Rafael J. Wysocki wrote: > On Tuesday, March 13, 2018 12:23:34 PM CET Tomasz Figa wrote: > > On Tue, Mar 13, 2018 at 7:34 PM, Vivek Gautam wrote: > > > On Tue, Mar 13, 2018 at 3:45 PM, Tomasz Figa wrote: > > >> On Tue, Mar 13, 2018 at 5:55 PM, 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. > > >> > > >> I'm wondering if this API would be useful for anything else that the > > >> problem we're trying to solve with deleting links without storing them > > >> anywhere. Perhaps a device_link_del_dev(consumer, supplier) would be a > > >> better alternative? > > > > > > Yea, that sounds simpler i think. Will add this API instead of > > > find_link(). Thanks. > > > > Perhaps let's wait for a moment to see if there are other opinions. :) > > > > Rafael, Lucas, any thoughts? > > It is not clear to me what the device_link_del_dev(consumer, supplier) > would do. The point appears to be that the pointer to the device_link need not be stored somewhere for later deletion. The newly added function would check if a device link exists and delete it if so. However I don't understand why storing the pointer would be a problem? Also, would using DL_FLAG_AUTOREMOVE avoid the need for the additional function? Thanks, Lukas