Hi Vivek,
On Wed, Mar 14, 2018 at 5:14 PM, Vivek Gautam
<vivek.gautam@xxxxxxxxxxxxxx> wrote:
> From: Sricharan R <sricharan@xxxxxxxxxxxxxx>
>
> 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 <sricharan@xxxxxxxxxxxxxx>
> Signed-off-by: Vivek Gautam <vivek.gautam@xxxxxxxxxxxxxx>
> Reviewed-by: Tomasz Figa <tfiga@xxxxxxxxxxxx>
> ---
>
> Changes since v9:
> - Using device_link_del_dev() to delete the device link, instead of
> doing it in two steps - device_link_find() to first find the link, and
> then calling device_link_del().
>
> drivers/iommu/arm-smmu.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 56a04ae80bf3..4cf270ffd449 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1460,10 +1460,31 @@ static int arm_smmu_add_device(struct device *dev)
>
> iommu_device_link(&smmu->iommu, dev);
>
> + if (pm_runtime_enabled(smmu->dev)) {
> + struct device_link *link;
> +
> + /*
> + * Establish the link between smmu and master, so that the
> + * smmu gets runtime enabled/disabled as per the master's
> + * needs.
> + */
> + link = device_link_add(dev, smmu->dev, DL_FLAG_PM_RUNTIME);
> + if (!link) {
> + dev_warn(smmu->dev,
> + "Unable to add link to the consumer %s\n",
> + dev_name(dev));
> + ret = -ENODEV;
> + goto out_unlink;
> + }
> + }
If it's an error, we should use dev_err(). Also, as per Robin's
comment for v9 could we make it as follows?
if (pm_runtime_enabled(smmu->dev) &&
!device_link_add(dev, smmu->dev, DL_FLAG_PM_RUNTIME)) {
dev_err(smmu->dev,
"Unable to add link to the consumer %s\n",
dev_name(dev));
ret = -ENODEV;
goto out_unlink;
}
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
