Received: by 10.223.185.111 with SMTP id b44csp147414wrg; Fri, 9 Mar 2018 02:41:34 -0800 (PST) X-Google-Smtp-Source: AG47ELsKHI5qAe5aR/LZ84OeSFSETLCUb2pgm1hBm3DMU3+2wCrdEKlkS4rbrRrxOpySFeJe47lW X-Received: by 2002:a17:902:5a5:: with SMTP id f34-v6mr316574plf.134.1520592094465; Fri, 09 Mar 2018 02:41:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520592094; cv=none; d=google.com; s=arc-20160816; b=ZaHzTk1FvSUhYhbYIClv5/nQnMXxmzzF85szbEIrFgtLNYHUklLy7X0HScEvf0z/e2 Ee4QmJOuTf2mNo/gHaO6N8Igdpukk4rEm4nj1DpQDfwQ8uPYSnPcp4lEohVRZ5TF4+y6 KObAX9+0u2UYnsYtV7AfjTQYr1ycohWOmoE9n4tYp5CKKokQfTPsf4fwo7Iqg9WeL/IR iM27ryMCVHev/VpSjp/gn89cb6d5ixEao1CEnpV1IFpKYow6gFviu1mIdg5+/5QkUOoF z1NyMRa64lA0oPD/wKZ7lr3C5Nze8VW2gK4L8FRaattBQUZ4kzAW/lN9MBBRUJfo+Jo6 OSnA== 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=1HJLvtX4THpTbTThpDhcH9Gl/LSo9+yJCXHJQHvnBRk=; b=M9tTCu19HHFcqEAPQ+epv5SHxca/jdoMNTa5IAaLUMACUsIVdyk/ivaxFHVvUaUfTa QJPMWqik2q/QBgK51z7x76suCJng7YgJn1OPrkCz0pPF0albOgM7HHHKbxZ6Cwork4Zu MuUeAw+6btkmYqtZnfebTYkCi8PXapoiQa2YUzaN+w3A0OUwJ5Zt7IIRSxzZbE+Bkr1J 3XyXc+6yK9G3c8xfoQdXgRp8+a0FujLrbH6uUTsU8ryBKu/wxXCt9Y6qbRm1p1iQf3Q3 CkZXhlR8VIDbHr5FrjKRfeHjBs9B9OqVSdbJrQl/G1DNCrOpUi38kRL3tZ9nUtx2AXah fzug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=YbuPXCWF; dkim=pass header.i=@codeaurora.org header.s=default header.b=GwXdKxZC; 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 t193si561159pgb.156.2018.03.09.02.41.19; Fri, 09 Mar 2018 02:41:34 -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=YbuPXCWF; dkim=pass header.i=@codeaurora.org header.s=default header.b=GwXdKxZC; 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 S1751184AbeCIKkW (ORCPT + 99 others); Fri, 9 Mar 2018 05:40:22 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:56258 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751067AbeCIKkT (ORCPT ); Fri, 9 Mar 2018 05:40:19 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 74DA160763; Fri, 9 Mar 2018 10:40:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520592018; bh=AZXX7R57ohTfetBKWvd0tD/f86JNHLIhFqtelsN4zGY=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=YbuPXCWFVNLO37e/xQbg31v5DyISNtRnWPMu0xxw5GlJGxVYJlbSJcT1qj4aMCHDI 7wz5rkHknpSiaHTJoDvuBQjDw5SoUImMgfTRYL+UggeYCR+k6xw3gKJJp6y6lFv57j 6t7RHvTahlo2WFB3TgcGMYNZ6dFaDdwY1UP22JLo= 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-f180.google.com (mail-qt0-f180.google.com [209.85.216.180]) (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 DA8896050D; Fri, 9 Mar 2018 10:40:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520592017; bh=AZXX7R57ohTfetBKWvd0tD/f86JNHLIhFqtelsN4zGY=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=GwXdKxZCdGtnIZh2F17CJtVRovzqoql6WGYbmzMwaZos7vp+iiw0zrgCbbh0Py5+m HGuOLCnyZsynbDefvyqntGW36ktr9ihVMCsMc3VS2FVkdWCjjeWZ9eVHymOTWUWCuB /Dh5k7m16FCb4V6Dq+m813qJQCho9WfSEnxF/hyk= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org DA8896050D 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-f180.google.com with SMTP id r16so10174485qtm.4; Fri, 09 Mar 2018 02:40:16 -0800 (PST) X-Gm-Message-State: AElRT7HFnECnhSrK12ouBYb5xvReuRtCtmHmvaqlbAe815zm7Ewrw5gw MD/c6RDMl4xV1ZESgwa4CaDOyTYaAmhKzIClwvA= X-Received: by 10.237.35.133 with SMTP id j5mr43331693qtc.122.1520592015988; Fri, 09 Mar 2018 02:40:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.83.10 with HTTP; Fri, 9 Mar 2018 02:40:15 -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 16:10:15 +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 Cc: "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , "robh+dt" , Mark Rutland , "Rafael J. Wysocki" , 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 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? > >> }; >> 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... Also, noticed one more thing while testing on sdm845. When we are conditionally enabling the runtime pm, we should create the device link too conditionally, i.e. only in the case the smmu->dev has runtime pm_enabled we can create this device link between smmu and the master device. Otherwise when the master tries to do a pm_runtime_get() over itself, the device link will ensure that pm_runtime_get() for smmu is done first. But that will fail when we don't have pm runtime enabled over smmu, and so the master device's pm_runtime_get() will fail too. Will fix this in the next version. Thanks 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