Received: by 10.213.65.68 with SMTP id h4csp938029imn; Wed, 14 Mar 2018 04:58:06 -0700 (PDT) X-Google-Smtp-Source: AG47ELtWzzLSI0x8kHkNZBoGG4VVplvNhh50njTkDxHDHgg0+98RkbAP/QpTq8/6C6nEUDU5jvy2 X-Received: by 10.98.232.6 with SMTP id c6mr4017367pfi.242.1521028685894; Wed, 14 Mar 2018 04:58:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521028685; cv=none; d=google.com; s=arc-20160816; b=EX7zy1oDXQf0N85q3r7LU9elIVkVTl3G5TDqPmmtzFAgfFajOXVb/nEHnANihmNMqe /uBPBPxpcpABOFugcOhn3vr+puqJ1owGWHWDkO0WfVSuxsJwtjjFphsfxcbR4qxHXDwi v7bHXcpWzBITW+NydjxrHSewAJnBaU4NEmPZPj13txP99++1i8QZMv7qhHcsStwmEZU4 2Bi/A7TF4xOTuuFU96yU4yaDMKnm4keFDzAAIRnASHV++CDGc/KXb+M4u+NI+SOV4qLX aLpX+dtiMC+8a1r4JgAPhOLHpZgwo3TFzgVLeJvHHgIYX4H+AfOA3bmLLMocA78UyWNN rQBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=e6u6MhHqOvfsPV0Ok6J8Kw+bZYFUuf75WR0H0sJtfKc=; b=lXykZFYAbN2mCch9QkETvXLBpMJ5woMQc8lL4v3uworX0LCRfeVcqY1g1vTp0opZXO SOtDv/ccG4XLHTIMlJvKj5zkwBKIAV+/bczTcF2WTbbhE3O//mXkiFZD2dIBLeZ8U1Xb 4jX+Zu/qS687xZnEAVMSo8rBZ93lXafQAKPmvFQfVAHd+CwJW3OZ1dM8pILiEZi8ktlL 72mRXk99EB0ZGB+MQrg38gAf4s27uemxQMS6C09TcYm9KzNTKnN8o2SdtSEpY6sqInEj sZXr2q4MZ/4k6XEhLm3XiLEBXUsg+pIQYHRc84adqNFICY5uRprAAKdSnBcfnPbw74S8 qqcQ== 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 x22si1940950pfm.321.2018.03.14.04.57.51; Wed, 14 Mar 2018 04:58:05 -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 S1751860AbeCNL4k (ORCPT + 99 others); Wed, 14 Mar 2018 07:56:40 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:43007 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751413AbeCNL4h (ORCPT ); Wed, 14 Mar 2018 07:56:37 -0400 Received: from 79.184.254.228.ipv4.supernova.orange.pl (79.184.254.228) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83) id d4d838966616711a; Wed, 14 Mar 2018 12:56:35 +0100 From: "Rafael J. Wysocki" To: Tomasz Figa Cc: Vivek Gautam , Lukas Wunner , 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 Date: Wed, 14 Mar 2018 12:57:11 +0100 Message-ID: <2705105.V6KYPvoJqj@aspire.rjw.lan> In-Reply-To: References: <20180313085534.11650-1-vivek.gautam@codeaurora.org> <2217404.A2W3Iek6du@aspire.rjw.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, March 14, 2018 12:50:54 PM CET Tomasz Figa wrote: > On Wed, Mar 14, 2018 at 8:12 PM, 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: > >> > Hi Tomasz, > >> > > >> > On Tue, Mar 13, 2018 at 3:45 PM, Tomasz Figa wrote: > >> >> Hi Vivek, > >> >> > >> >> Thanks for the patch. > >> >> > >> >> 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. > > It would delete a link between consumer and supplier. If there's one I suppose. I'm wondering if you are somehow trying to address the same problem as the device links reference counting patch from Lukas that has been queued up for 4.17 already. Thanks, Rafael