linux-kernel - Re: [PATCH 2/3] usb: xhci: tegra: Add runtime PM support

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: <1fff9fc1-2ad2-dba1-cb1d-d531254984ce@intel.com>
Date:   Fri, 9 Mar 2018 11:13:02 +0200
From:   Mathias Nyman <mathias.nyman@...el.com>
To:     Thierry Reding <thierry.reding@...il.com>,
        Jon Hunter <jonathanh@...dia.com>
Cc:     Mathias Nyman <mathias.nyman@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] usb: xhci: tegra: Add runtime PM support

On 09.03.2018 10:36, Thierry Reding wrote:
> On Thu, Mar 08, 2018 at 09:31:07PM +0000, Jon Hunter wrote:
>>
>> On 01/03/18 14:18, Mathias Nyman wrote:
>>> On 14.02.2018 18:34, Jon Hunter wrote:
>>>> Add runtime PM support to the Tegra XHCI driver and move the function
>>>> calls to enable/disable the clocks, regulators and PHY into the runtime
>>>> PM callbacks.
>>>>
>>>> Signed-off-by: Jon Hunter <jonathanh@...dia.com>
>>>> ---
>>>>    drivers/usb/host/xhci-tegra.c | 80
>>>> ++++++++++++++++++++++++++++++-------------
>>>>    1 file changed, 56 insertions(+), 24 deletions(-)
>>>>
>>>> diff --git a/drivers/usb/host/xhci-tegra.c
>>>> b/drivers/usb/host/xhci-tegra.c
>>>> index 02b0b24faa58..42aa67858b53 100644
>>>> --- a/drivers/usb/host/xhci-tegra.c
>>>> +++ b/drivers/usb/host/xhci-tegra.c
>>>> @@ -18,6 +18,7 @@
>>>>    #include <linux/phy/tegra/xusb.h>
>>>>    #include <linux/platform_device.h>
>>>>    #include <linux/pm.h>
>>>> +#include <linux/pm_runtime.h>
>>>>    #include <linux/regulator/consumer.h>
>>>>    #include <linux/reset.h>
>>>>    #include <linux/slab.h>
>>>> @@ -1067,22 +1068,12 @@ static int tegra_xusb_probe(struct
>>>> platform_device *pdev)
>>>>         */
>>>>        platform_set_drvdata(pdev, tegra);
>>>>    -    err = tegra_xusb_clk_enable(tegra);
>>>> -    if (err) {
>>>> -        dev_err(&pdev->dev, "failed to enable clocks: %d\n", err);
>>>> -        goto put_usb2;
>>>> -    }
>>>> -
>>>> -    err = regulator_bulk_enable(tegra->soc->num_supplies,
>>>> tegra->supplies);
>>>> -    if (err) {
>>>> -        dev_err(&pdev->dev, "failed to enable regulators: %d\n", err);
>>>> -        goto disable_clk;
>>>> -    }
>>>> +    pm_runtime_enable(&pdev->dev);
>>>>    -    err = tegra_xusb_phy_enable(tegra);
>>>> +    err = pm_runtime_get_sync(&pdev->dev);
>>>>        if (err < 0) {
>>>
>>> Does this mean that if runtime PM is disabled then clocks and regulator
>>> will never be enabled
>>> for Tegra xhci?
>>>
>>> How about keeping the clock and regualtor enabling in probe, and instead
>>> add something like:
>>>
>>> pm_runtime_set_active(&pdev->dev);
>>> pm_runtime_enable(&pdev->dev);
>>> pm_runtime_get_noresume(&pdev->dev);
>>
>> For 64-bit Tegra there is a dependency on CONFIG_PM, but for 32-bit
>> AFAIK there is not and so yes we should handle the case when PM_RUNTIME
>> is disabled.
>>
>> Typically we do something like ...
>>
>>      pm_runtime_enable(&pdev->dev);
>>      if (!pm_runtime_enabled(&pdev->dev))
>> 	ret = tegra_xusb_runtime_resume(&pdev->dev);
>>      else
>>          ret = pm_runtime_get_sync(&pdev->dev);
>>
>> That way we can keep the regulator and clock stuff in the handler. I
>> will update this series.
> 
> Is there any good reason why we don't depend on PM for 32-bit as well?
> I'm not aware of any differences in drivers that are 32-bit specific for
> Tegra, and I'm not even sure the !PM case gets any testing at all. And
> even if, do we really still want to support that?
> 
> I don't see any advantage these days for having it disabled.

I don't know much about Tegra, but I'd still like to turn this question around:

Is there any reason why clks and regulators can't initially be turned on in probe,
and then let runtime PM handle them later if PM is supported?

Shouldn't this work in all cases, and it avoids creating new dependencies?

Thanks
Mathias