On Thu, Mar 15, 2018 at 2:50 AM, Robin Murphy <robin.murphy@xxxxxxx> wrote:
> On 13/03/18 08:55, Vivek Gautam 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>
>> ---
>> drivers/iommu/arm-smmu.c | 29 +++++++++++++++++++++++++++++
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 56a04ae80bf3..64953ff2281f 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) {
>
>
> FWIW, given that we don't really care about link itself, I'd be quite happy
> to simplify that lot down to:
>
> if (pm_runtime_enabled(smmu_dev) &&
> !device_link_add(dev, smmu->dev, DL_FLAG_PM_RUNTIME)) {
>
>> + dev_warn(smmu->dev,
>> + "Unable to add link to the consumer
>> %s\n",
>> + dev_name(dev));
>
>
> (side note: since device_link_add() already prints a message on success,
> maybe it could print its own failure message too?)
I think we care whether adding the link succeeded. If it fails to be
added, we might end up with a complete system lockup on a system with
power domains.
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
