From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vivek Gautam Subject: Re: [PATCH v8 4/5] iommu/arm-smmu: Add the device_link between masters and smmu Date: Fri, 9 Mar 2018 12:41:46 +0530 Message-ID: References: <20180302101050.6191-1-vivek.gautam@codeaurora.org> <20180302101050.6191-5-vivek.gautam@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Robin Murphy , "Rafael J. Wysocki" Cc: Mark Rutland , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Stephen Boyd , Will Deacon , "list-Y9sIeH5OGRo@public.gmane.org:IOMMU DRIVERS , Joerg Roedel , " , open list , robh+dt , linux-arm-msm List-Id: linux-arm-msm@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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751229AbeCIHLv (ORCPT ); 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 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 X-Google-Smtp-Source: AG47ELuj6ASc+jW7CiSOwKL5cY2+siGnXKBC9t4hD3aPfk6lQoT0agPKmcQJa4M9l/8NNMvgbXw4QwKlYyepVww9pmw= MIME-Version: 1.0 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 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