lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 15 Mar 2018 10:44:32 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Tomasz Figa <tfiga@...omium.org>
Cc:     Vivek Gautam <vivek.gautam@...eaurora.org>,
        Joerg Roedel <joro@...tes.org>,
        Rob Herring <robh+dt@...nel.org>,
        "open list:IOMMU DRIVERS" <iommu@...ts.linux-foundation.org>,
        devicetree@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        Will Deacon <will.deacon@....com>,
        Rob Clark <robdclark@...il.com>,
        Sricharan R <sricharan@...eaurora.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Archit Taneja <architt@...eaurora.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v9 4/5] iommu/arm-smmu: Add the device_link between
 masters and smmu

On 15/03/18 06:18, Tomasz Figa wrote:
> On Thu, Mar 15, 2018 at 2:50 AM, Robin Murphy <robin.murphy@....com> wrote:
>> On 13/03/18 08:55, Vivek Gautam wrote:
>>>
>>> From: Sricharan R <sricharan@...eaurora.org>
>>>
>>> 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@...eaurora.org>
>>> Signed-off-by: Vivek Gautam <vivek.gautam@...eaurora.org>
>>> Reviewed-by: Tomasz Figa <tfiga@...omium.org>
>>> ---
>>>    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.

Well, yeah, that was implicit - the point is that we *only* care about 
whether it succeeded or not. Thus we may as well just check for NULL 
directly instead of assigning the value as if we were actually going to 
do anything with it.

Robin.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ