Received: by 10.213.65.68 with SMTP id h4csp915504imn; Wed, 14 Mar 2018 04:12:39 -0700 (PDT) X-Google-Smtp-Source: AG47ELv7rm760MyL+GQkYVxPe2jlW0R7rXku/2oj79Uk/rgudjxUY8F4GX4TYwsL0Y6KV1ns86Pl X-Received: by 10.99.119.137 with SMTP id s131mr3261506pgc.296.1521025959808; Wed, 14 Mar 2018 04:12:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521025959; cv=none; d=google.com; s=arc-20160816; b=iTW263F96OKk4zmRj3/dN6KIf3CmgsM/6NwhIzUK3Vx2Ul8KUt6AbYZhxkm9nrQjim RdpxQsP6dIp9Y+JuvJ+r3It84WeUBIU4vSkK4bvJKw0JmBXiV6Em5W8loyAJUlLxMSgr rs23EBqH5FmAHerzqI73KipT61Ga4aM7M3gGMdId6E8+I535YwkVLTwvulxxirsRHHyA ufbRjrOSP/n79htOby5hni2YbsNV+0CpPl1SgA1nlkgh3ECyJ+DM4nAMC4vpn1R9mWD+ RgYtfdMlM1jo4uJ5z4C3Q4U00U7h+kEQ1TuWZ9WjbXrzesLGdCKtC79w/cMkt9uTqleh hfTw== 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=1hP80c7DKu8O+UYVLQxnw4xTB1YG2bCc4Pq0R9LwwvM=; b=H91bvgStNdZgr19R6ODmqJhqot/6p4f/+fCJNFfQrxduBduL4zF71OdAU8lDK1/+oU aAylzQNs3k56oObk66u0ZAew6mGc+VhPW+oXJeJiqQ5JYhHnVwXLPUQ/z3PtrNUNXD9v Fe4TKIRdVIGol6TsmF0GfadAYUXT4i2xuztJcRHF39EojJFRHf3x/s7x451PwWN3vVQ9 F0/bB/BREAGGYFAK8ZAvEW4suE5sIP0JtPhtuwGhq+LrZaYcJHNmto4PeJLXSELljnmz 5pq3MeNRi3rdJIuGItX0vbE1q9ImhDg3/o1GndYaWUDxdodcZiIRHS7VQ88ZMhrhaWTk suRQ== 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 m24si1927819pfi.66.2018.03.14.04.12.25; Wed, 14 Mar 2018 04:12:39 -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 S1751565AbeCNLLe (ORCPT + 99 others); Wed, 14 Mar 2018 07:11:34 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:59064 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750751AbeCNLLc (ORCPT ); Wed, 14 Mar 2018 07:11:32 -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 d0396deb80c557dd; Wed, 14 Mar 2018 12:11:30 +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:12:05 +0100 Message-ID: <2217404.A2W3Iek6du@aspire.rjw.lan> In-Reply-To: References: <20180313085534.11650-1-vivek.gautam@codeaurora.org> 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 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. Thanks, Rafael