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]
Message-ID: <4865efd5e746d2e94cc4680a47a30a0d@codeaurora.org>
Date:   Thu, 17 Sep 2020 06:37:44 +0530
From:   mansur@...eaurora.org
To:     Stephen Boyd <swboyd@...omium.org>
Cc:     linux-media@...r.kernel.org, stanimir.varbanov@...aro.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        vgarodia@...eaurora.org
Subject: Re: [PATCH 1/2] venus: core: change clk enable and disable order in
 resume and suspend

> On 2020-09-09 00:05, Stephen Boyd wrote:
>> Quoting Mansur Alisha Shaik (2020-09-07 20:44:05)
>>> Currently video driver is voting after clk enable and un voting
>>> before clk disable. Basically we should vote before clk enable
>>> and un vote after clk disable.
>>> 
>>> Corrected this by changing the order of clk enable and clk disable.
>>> 
>>> Signed-off-by: Mansur Alisha Shaik <mansur@...eaurora.org>
>>> ---
>> 
>> Any Fixes: tag?
Added Fixes tag
>> 
>>>  drivers/media/platform/qcom/venus/core.c | 17 ++++++++++-------
>>>  1 file changed, 10 insertions(+), 7 deletions(-)
>>> 
>>> diff --git a/drivers/media/platform/qcom/venus/core.c 
>>> b/drivers/media/platform/qcom/venus/core.c
>>> index c5af428..4857bbd 100644
>>> --- a/drivers/media/platform/qcom/venus/core.c
>>> +++ b/drivers/media/platform/qcom/venus/core.c
>>> @@ -363,13 +363,16 @@ static __maybe_unused int 
>>> venus_runtime_suspend(struct device *dev)
>>>         if (ret)
>>>                 return ret;
>>> 
>>> +       if (pm_ops->core_power) {
>>> +               ret = pm_ops->core_power(dev, POWER_OFF);
>>> +               if (ret)
>>> +                       return ret;
>>> +       }
>>> +
>>>         ret = icc_set_bw(core->cpucfg_path, 0, 0);
>>>         if (ret)
>>>                 return ret;
>> 
>> Shouldn't we power it back up if this fails during suspend?
On icc_set_bw() failure, we are just power it and return.
Addressed these comments and posted new version
https://lore.kernel.org/patchwork/project/lkml/list/?series=463224
>> 
>>> 
>>> -       if (pm_ops->core_power)
>>> -               ret = pm_ops->core_power(dev, POWER_OFF);
>>> -
>>>         return ret;
>>>  }
>>> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ