Received: by 10.223.185.116 with SMTP id b49csp3428093wrg; Tue, 13 Feb 2018 02:15:50 -0800 (PST) X-Google-Smtp-Source: AH8x226yUnwrTgs+Ec2nbu6/c2gN60mqqUYMZpYPELKmfDY51RhUcSfhSeICEYSCjVkYXUoDJg08 X-Received: by 10.98.247.9 with SMTP id h9mr401864pfi.212.1518516950722; Tue, 13 Feb 2018 02:15:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518516950; cv=none; d=google.com; s=arc-20160816; b=GuTk4zx7xgdZrkOEgP49SVireUYXn1AkUklDUgHcHgc+1Im2Sh22GDpSC7pSsRUthA edh0Kvo2v61wmojxxjTj4OvilC63BdCnPurR9XWMecaPeDzWcu33ImwG6OygR2PSDNm7 0GGMCwqYmJgpiwN99r4HKSzUt1DxyP+i4EsqRnywLr4J4Bd9SZbZskmws+Ch4VOU5JU4 8RLGpeROp1NCPQZ0XK6c8xie8tikaI7510qE8yv6dmQnFeo/iTIjbbF9zAHmNrDn8acO bdWZbiCniNs+CbtkoGg1AjirOi2ZqaY+0rsYOLTxHLvurZoJK56SDLO7jYLrgnBOT4Y7 1bFg== 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=3nmBtqUlz+zFQJ4JefP9nO51wDITPjyBS/4Ox3NpoCU=; b=yF/mTmzi/Yy28Wg3VXOPyjW1RgOAunoTX4RIOAkyr3KNzpwrWgpyz5jsJ5DmbBP3Va uIQDHKjsAWMaslybWpHFNhQF/vM49WaN7xoaOD8U5SDNsr0FsTLHZOenz2B0akLH6QkV xFRvNgdnO9BkMGeU3qZvbEZMZ+gVeVOGSTpRO/6W0I2L17AMpZtMAfYH/naew1+RVrep QBR55dyzXO3oi254bLdKLqFkmkcJ2JBlvOm5t4MjaBAmAR0hDVBSMLmGS6bGFxRueaPv EyUpM+PjHG346xJsTdG374toIdokRhGdN0Reanrs9mum7sqmUdZuk+eZONyttNGIINmp P9HA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=fVUJfbsD; dkim=pass header.i=@codeaurora.org header.s=default header.b=Xu9JiEbG; 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 q20-v6si993016pll.300.2018.02.13.02.15.35; Tue, 13 Feb 2018 02:15:50 -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=fVUJfbsD; dkim=pass header.i=@codeaurora.org header.s=default header.b=Xu9JiEbG; 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 S934026AbeBMKOX (ORCPT + 99 others); Tue, 13 Feb 2018 05:14:23 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:44208 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933825AbeBMKOT (ORCPT ); Tue, 13 Feb 2018 05:14:19 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 06D0C60F6D; Tue, 13 Feb 2018 10:14:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518516859; bh=e14zu7riuq5mqKy2fxQC5HeUN9kbf60OV33opL35EBI=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=fVUJfbsDRq+MGA9/oU8/tdlIorNMrYlVpdxneamcICd5xAfbGZROFrAXBM2OMakJs /yUuTP3bWDxrh9zS+t/vbBnOHXQfW41sLwDwNh32ffC8KzppAzJLVCO3oqDSC7+1G+ 8h3Z/2YVC38X3S2udelGjaQsbUkTVSKBGQ3hxaDA= 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-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) (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 C492C60F72; Tue, 13 Feb 2018 10:14:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518516857; bh=e14zu7riuq5mqKy2fxQC5HeUN9kbf60OV33opL35EBI=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=Xu9JiEbGmpBi0jAA4Qo16/pnauUfyK3W+AZxCjx85XRMDkGCU8zK4VUFZVArjT8/h TY59AOlHyr8utP6p0Sw4EG41mMJrx5FyBv98cuY0KnmYOF1pd6eRh5MpgBUekqgq/Y jmoy7tHB+lx/rXMikhfbU2C/PsmQ71yTIal9/zFg= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org C492C60F72 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-qk0-f177.google.com with SMTP id e20so21890168qkm.7; Tue, 13 Feb 2018 02:14:17 -0800 (PST) X-Gm-Message-State: APf1xPCXDndX71l8tEYN6WHJ/gPjLzk7Zc9MlUVFSRwhxdlp7Z+OPynW HEUEiZvRZiEKUrDzIGVJpgjObmA1gEaL46u6bPs= X-Received: by 10.55.43.70 with SMTP id r67mr978658qkh.17.1518516856936; Tue, 13 Feb 2018 02:14:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.8.227 with HTTP; Tue, 13 Feb 2018 02:14:16 -0800 (PST) In-Reply-To: References: <1517999482-17317-1-git-send-email-vivek.gautam@codeaurora.org> <1517999482-17317-5-git-send-email-vivek.gautam@codeaurora.org> From: Vivek Gautam Date: Tue, 13 Feb 2018 15:44:16 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 4/6] iommu/arm-smmu: Add the device_link between masters and smmu To: Tomasz Figa Cc: "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Rob Herring , Mark Rutland , "Rafael J. Wysocki" , Robin Murphy , Will Deacon , Rob Clark , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , devicetree@vger.kernel.org, open list , Linux PM , dri-devel , freedreno@lists.freedesktop.org, David Airlie , Greg KH , Stephen Boyd , 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 Hi Tomasz, On Tue, Feb 13, 2018 at 2:01 PM, Tomasz Figa wrote: > Hi Vivek, > > Thanks for the patch. Please see my comments inline. Thanks for reviewing the patch series. > > On Wed, Feb 7, 2018 at 7:31 PM, 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 | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c >> index c024f69c1682..c7e924d553bd 100644 >> --- a/drivers/iommu/arm-smmu.c >> +++ b/drivers/iommu/arm-smmu.c >> @@ -215,6 +215,9 @@ struct arm_smmu_device { >> >> /* IOMMU core code handle */ >> struct iommu_device iommu; >> + >> + /* runtime PM link to master */ >> + struct device_link *link; >> }; >> >> enum arm_smmu_context_fmt { >> @@ -1425,6 +1428,17 @@ static int arm_smmu_add_device(struct device *dev) >> >> pm_runtime_put_sync(smmu->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); >> + if (!smmu->link) >> + dev_warn(smmu->dev, >> + "Unable to create device link between %s and %s\n", >> + dev_name(smmu->dev), dev_name(dev)); > > How likely it is that the master can work normally even if the link > add fails? Perhaps we should just return an error here? Right. We are assuming that the power is handled for most of the smmu operations, after we add the master with smmu, based on the fact that the device link is successful. We should return error code here. Will make the necessary change. > >> + >> return 0; >> >> out_rpm_put: >> @@ -1449,6 +1463,8 @@ static void arm_smmu_remove_device(struct device *dev) >> cfg = fwspec->iommu_priv; >> smmu = cfg->smmu; >> >> + device_link_del(smmu->link); > > We allowed smmu->link in arm_smmu_add_device(), but here we don't > check it. Looking at the code, device_link_del() doesn't seem to check > either. > > Note that this problem would go away if we fail add_device on > device_link_add() failure, as I suggested above, so no change would be > necessary. Sure. After making the above change, this should also be handled. Best regards Vivek > > Best regards, > Tomasz -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation