Received: by 10.223.185.111 with SMTP id b44csp256840wrg; Fri, 9 Mar 2018 04:35:57 -0800 (PST) X-Google-Smtp-Source: AG47ELt1KX2J8XYiel65FECUdk9huFwPYi5j/BxCMEAzpJlGeCIoyKCvIzV1DQTKlffadjhype8f X-Received: by 10.99.183.5 with SMTP id t5mr24658187pgf.416.1520598957021; Fri, 09 Mar 2018 04:35:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520598956; cv=none; d=google.com; s=arc-20160816; b=lhci8nHedh03JV/9ZBSTkp3G1B5SiwXa+Ps5g/1Z54xK53rSn6vnwvCy7JG75yU+ee fIPwmuuVc8P5HUWPG8jahwnWg9nUA5VgoCjKMzB6ervwDbZ7FHLLiNpnBYmw6pMwT2em QPRBmTLFCmgbDxRh7rclJ/aT5DXiBtGl4mWaWBEiHQtA/T77aue/bnBVAaxY9ECi89pb NlptSKggSvt3z0y5Euvh4lRZvNUYNFlFsVg5kh5qmLGnLd606IPU80FKn8MJjIExgWK9 E2myB+lA78W9ohYC0Qt4kv+HEWyDz0Z3AHXvx1a2hABSbypdd8VS5G6e0vyaLsEXav0v DvaA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=cuijEGgbogHIul8LIAk4+1v0BXrSeHPnUCtso0pRrDo=; b=QNgGIYKvljpIoOK6PxFpdte+bPz7wphyY3SD1MvtBKOGxssxLYzPB563lWL/4UFdHc VPIY1H0N7mZ08LxmgTSfpDX9dBR0OMda6CTrV4DlSKcg1eC82NqcsLVNK6Ok30A2563E uyNJ3Om/H7RFQBb5NvzKWt7bZBvlGmciG52/h7sbAQtn+xwW/9IPkmepWjfZ9uR8puJ5 wYO4ROyWB7hDgDt5hrqQSsxtZgHAXgXI0Uvwqd/bf3SRClyz9P0c2dYIxQpGHJcllndy QOrcbcjmK91kEdHxOj8jvmebAALXlO062ugVKuQo1Q3n5TH/NhenaQH9CdBUVWZZTS/a vAPQ== 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 y2si675002pgs.359.2018.03.09.04.35.41; Fri, 09 Mar 2018 04:35:56 -0800 (PST) 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 S932085AbeCIMet (ORCPT + 99 others); Fri, 9 Mar 2018 07:34:49 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:51140 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932067AbeCIMer (ORCPT ); Fri, 9 Mar 2018 07:34:47 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4768D1529; Fri, 9 Mar 2018 04:34:47 -0800 (PST) Received: from [10.1.210.88] (e110467-lin.cambridge.arm.com [10.1.210.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 031513F487; Fri, 9 Mar 2018 04:34:43 -0800 (PST) Subject: Re: [PATCH v8 4/5] iommu/arm-smmu: Add the device_link between masters and smmu To: "Rafael J. Wysocki" Cc: Vivek Gautam , "list@263.net:IOMMU DRIVERS" , Joerg Roedel , joro@8bytes.org, robh+dt , Mark Rutland , Will Deacon , Rob Clark , "list@263.net:IOMMU DRIVERS" , Joerg Roedel , iommu@lists.linux-foundation.org, devicetree@vger.kernel.org, open list , Tomasz Figa , jcrouse@codeaurora.org, Stephen Boyd , Sricharan R , Marek Szyprowski , Archit Taneja , linux-arm-msm References: <20180302101050.6191-1-vivek.gautam@codeaurora.org> <20180302101050.6191-5-vivek.gautam@codeaurora.org> From: Robin Murphy Message-ID: Date: Fri, 9 Mar 2018 12:34:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/03/18 07:11, Vivek Gautam wrote: > On Thu, Mar 8, 2018 at 10:29 AM, Vivek Gautam > wrote: >> On Wed, Mar 7, 2018 at 6:17 PM, Robin Murphy wrote: >>> On 02/03/18 10:10, Vivek Gautam wrote: >>>> >>>> From: Sricharan R >>>> >>>> Finally add the device link between the master device and >>>> smmu, so that the smmu gets runtime enabled/disabled only when the >>>> master needs it. This is done from add_device callback which gets >>>> called once when the master is added to the smmu. >>>> >>>> Signed-off-by: Sricharan R >>>> Signed-off-by: Vivek Gautam >>>> --- >>>> drivers/iommu/arm-smmu.c | 21 +++++++++++++++++++++ >>>> 1 file changed, 21 insertions(+) >>>> >>>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c >>>> index 3d6a1875431f..bb1ea82c1003 100644 >>>> --- a/drivers/iommu/arm-smmu.c >>>> +++ b/drivers/iommu/arm-smmu.c >>>> @@ -217,6 +217,9 @@ struct arm_smmu_device { >>>> /* IOMMU core code handle */ >>>> struct iommu_device iommu; >>>> + >>>> + /* runtime PM link to master */ >>>> + struct device_link *link; >>> >>> >>> Just the one? > > we will either have to count all the devices that are present on the > iommu bus, or > maintain a list to which all the links can be added. > But to add the list, we will have to initialize a LIST_HEAD in struct > device_link > as well. > > Or, I think we don't even need to maintain a pointer to link with smmu. > In arm_smmu_remove_device(), we can find out the correct link, and delete it. > > list_for_each_entry(link, &dev->links.suppliers, c_node) > if (link->supplier == smmu->dev); > device_link_del(link); > > Should that be fine? > > Rafael, does the above snippet looks right to you? Context: smmu->dev > is the supplier, and dev is the consumer. We want to find the link, > and delete it. Actually, looking at the existing code, it seems like device_link_add() will in fact look up and return any existing link between a given supplier and consumer - is that intentional API behaviour that users may rely on to avoid keeping track of explicit link pointers? (or conversely, might it be reasonable to factor out a device_link_find() function?) Robin.