Received: by 10.223.185.82 with SMTP id b18csp214113wrg; Thu, 8 Mar 2018 23:13:00 -0800 (PST) X-Google-Smtp-Source: AG47ELuSJWE6yjX5BY6J8DkMtfItq4onjp/NgRhlpMpXZ/1L3ZbwMiKJVEzVv7VhhmLc52ZcqCKZ X-Received: by 2002:a17:902:8349:: with SMTP id z9-v6mr26208373pln.163.1520579580197; Thu, 08 Mar 2018 23:13:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520579580; cv=none; d=google.com; s=arc-20160816; b=EUjLZaAMttsISTYC28L9qkQZcA2J4FVXVYzWMF2i3iPX0YcQMWkhSm3xLkXjBhaFCC 4ON+hqEw7I0wCoHEuyo51q46Z1dYPX8iYpA7SUsBnu4Ic0JpycsvqaH69+X5ig232Z1P tHWLLDRz7igMnW69aJ9m1q/dgEjmYHumcbsah9RHF6IZaYX0DH5Y4Jd9w+sp+RUN0OJR +mgAqeTzvd2yKUuxv254dq2qBGrUaRoedC0yVZHIQwH/iE+6+w8T1yK354UrSQWofTUa fMIILmWiRnschZsSsVJ84Vw5f+oih4vuJgYqSJVwqpREf7c3Fem39qYQaGg/ovBbWKD4 4Bww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dmarc-filter:dkim-signature :dkim-signature:arc-authentication-results; bh=vYDtAsCBBonlJ7Sj3AKzJQAApOfWb+LYKjvuOiWXoNc=; b=GJ0bAAMVv7S8Dl5/YokDtIT1ujo6/XRQf5g8IPjf0Txh/jHZrmhQ8OSnjfnszXilfE 8C8iSgwEqzs1h0x0bHe/m+wRZaU39FRKbDCoCyNprrI2BMMw6d9MAhpMJfFYRdcXAIta Xkv7kztpZtdLTZnsaEgWlcc37d9T8c5DZ93nPIvi9omfGPCgscBowgYwHdAIs8zG6dDD dzvkFWqyzX+JlSGrB1f7lrr5QI5hO9OEwkfZv04+4UJkdajOvJzKNRXyOw6RKQq1EZwd MTF5rnqCsZNxmPwiS65ptGgaLiBaeM12faThjtFCmaLDE9711TkDpQxaIA+PGR+8IxgK z/vg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=e9fDTz8j; dkim=pass header.i=@codeaurora.org header.s=default header.b=Qv8SwviN; 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 g6si318104pgr.233.2018.03.08.23.12.45; Thu, 08 Mar 2018 23:13:00 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b=e9fDTz8j; dkim=pass header.i=@codeaurora.org header.s=default header.b=Qv8SwviN; 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 S1751219AbeCIHLv (ORCPT + 99 others); Fri, 9 Mar 2018 02:11:51 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:45744 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750913AbeCIHLt (ORCPT ); Fri, 9 Mar 2018 02:11:49 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 723F76038E; Fri, 9 Mar 2018 07:11:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520579508; bh=dnVsq3Zt1UbXmiwQqeIgfWf8PuSUeaAiTho5IX/JC+E=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=e9fDTz8jy/7ufngdjPLhSD+i3nLgzzZl3wO8m1FsrjCqt9AIwFXPhzwqp+SQnSIMZ TR+ubq2779TwmfhthW1tDv2DoCyDuqhdoYOygRYpdlpvyr1JicqSbnGjhH857sP2k4 f/huCS6cSZbgpniM3hyN8RdlK5VocTnomi6touPk= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com [209.85.216.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: vivek.gautam@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 5CF3360618; Fri, 9 Mar 2018 07:11:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520579507; bh=dnVsq3Zt1UbXmiwQqeIgfWf8PuSUeaAiTho5IX/JC+E=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=Qv8SwviNY0XpowTGj0jeGtSHsaTddn3KtSUXod+SF9QTCzWpGsTp34SkHAcWN9W6n xuUWBTGBRRtZE3Zz2BerxCTx0aYv5G7C1QOsUDOrWlojFzLcwRASuWfsp/JX8KNgM+ li/V437B/3KPxuwuqMmgdnsupZjqSeg4Git/kIGI= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 5CF3360618 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=vivek.gautam@codeaurora.org Received: by mail-qt0-f175.google.com with SMTP id v90so9664481qte.12; Thu, 08 Mar 2018 23:11:47 -0800 (PST) X-Gm-Message-State: AElRT7GX1pNzlG3WudvwPU886Dpz1ioHvmVB3BGJWrq6xvflcQ31qjLw Lyy/uSBbe7Nw5NF7CLd2FXDyP0LOinKS2tMPyN4= X-Received: by 10.200.19.7 with SMTP id e7mr43221230qtj.204.1520579506541; Thu, 08 Mar 2018 23:11:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.83.10 with HTTP; Thu, 8 Mar 2018 23:11:46 -0800 (PST) In-Reply-To: References: <20180302101050.6191-1-vivek.gautam@codeaurora.org> <20180302101050.6191-5-vivek.gautam@codeaurora.org> From: Vivek Gautam Date: Fri, 9 Mar 2018 12:41:46 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 4/5] iommu/arm-smmu: Add the device_link between masters and smmu To: Robin Murphy , "Rafael J. Wysocki" Cc: "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , "robh+dt" , Mark Rutland , Will Deacon , Rob Clark , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , devicetree@vger.kernel.org, open list , Tomasz Figa , jcrouse@codeaurora.org, Stephen Boyd , Sricharan R , Marek Szyprowski , Archit Taneja , linux-arm-msm Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. regards Vivek >> >>> }; >>> enum arm_smmu_context_fmt { >>> @@ -1470,10 +1473,26 @@ static int arm_smmu_add_device(struct device *dev) >>> iommu_device_link(&smmu->iommu, dev); >>> + /* >>> + * Establish the link between smmu and master, so that the >>> + * smmu gets runtime enabled/disabled as per the master's >>> + * needs. >>> + */ >>> + smmu->link = device_link_add(dev, smmu->dev, DL_FLAG_PM_RUNTIME); >> >> >> Maybe I've misunderstood how the API works, but AFAICS the second and >> subsequent devices are all just going to overwrite (and leak) the link of >> the previous one... > > Sorry, my bad. Will take care of this. > > regards > Vivek > >> >>> + if (!smmu->link) { >>> + dev_warn(smmu->dev, "Unable to create device link between >>> %s and %s\n", >>> + dev_name(smmu->dev), dev_name(dev)); >>> + ret = -ENODEV; >>> + goto out_unlink; >>> + } >>> + >>> arm_smmu_rpm_put(smmu); >>> return 0; >>> +out_unlink: >>> + iommu_device_unlink(&smmu->iommu, dev); >>> + arm_smmu_master_free_smes(fwspec); >>> out_rpm_put: >>> arm_smmu_rpm_put(smmu); >>> out_cfg_free: >>> @@ -1496,6 +1515,8 @@ static void arm_smmu_remove_device(struct device >>> *dev) >>> cfg = fwspec->iommu_priv; >>> smmu = cfg->smmu; >>> + device_link_del(smmu->link); >> >> >> ...and equivalently you end up with a double-free (or more) here of a link >> which may not have belonged to dev anyway. >> >> Robin. >> >> >>> + >>> ret = arm_smmu_rpm_get(smmu); >>> if (ret < 0) >>> return; >>> >> > > > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation