linux-kernel - Re: [PATCH V3 1/6] dmaengine: tegra-apb: Correct runtime-pm usage

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: <5649A339.20208@nvidia.com>
Date:	Mon, 16 Nov 2015 09:34:49 +0000
From:	Jon Hunter <jonathanh@...dia.com>
To:	Andy Shevchenko <andy.shevchenko@...il.com>
CC:	Laxman Dewangan <ldewangan@...dia.com>,
	Vinod Koul <vinod.koul@...el.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Alexandre Courbot <gnurou@...il.com>,
	dmaengine <dmaengine@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V3 1/6] dmaengine: tegra-apb: Correct runtime-pm usage


On 14/11/15 13:27, Andy Shevchenko wrote:
> On Fri, Nov 13, 2015 at 6:39 PM, Jon Hunter <jonathanh@...dia.com> wrote:
>> The tegra-apb DMA driver enables runtime-pm but never calls
>> pm_runtime_get/put and hence the runtime-pm callbacks are never invoked.
>> The driver manages the clocks by directly calling clk_prepare_enable()
>> and clk_unprepare_disable().
>>
>> Fix this by replacing the clk_prepare_enable() and clk_disable_unprepare()
>> with pm_runtime_get_sync() and pm_runtime_put(), respectively. Note that
>> the consequence of this is that if runtime-pm is disabled, then the clocks
>> will remain on the entire time the driver is loaded. However, if
>> runtime-pm is disabled, then power is not most likely not a concern.
>>
> 
> Have you tested these changes somehow?

Yes.

> See my comments below.
> 
>> Signed-off-by: Jon Hunter <jonathanh@...dia.com>
>> ---
>> V3 changes:
>> - Removed unnecessary update to local variables in suspend/resume
>> V2 changes:
>> - Fixed return value for allocating channel
>> - Fixed test for return value from pm_runtime_get_sync()
>>
>> drivers/dma/tegra20-apb-dma.c | 43 ++++++++++++++++++-------------------------
>>  1 file changed, 18 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
>> index c8f79dcaaee8..f68bccf55a24 100644
>> --- a/drivers/dma/tegra20-apb-dma.c
>> +++ b/drivers/dma/tegra20-apb-dma.c
>> @@ -1186,10 +1186,12 @@ static int tegra_dma_alloc_chan_resources(struct dma_chan *dc)
>>
>>         dma_cookie_init(&tdc->dma_chan);
>>         tdc->config_init = false;
>> -       ret = clk_prepare_enable(tdma->dma_clk);
>> +
>> +       ret = pm_runtime_get_sync(tdma->dev);
>>         if (ret < 0)
>> -               dev_err(tdc2dev(tdc), "clk_prepare_enable failed: %d\n", ret);
>> -       return ret;
>> +               return ret;
>> +
> 
>> +       return 0;
> 
> This is a non-reachable code.

No it is not.

>>  }
>>
>>  static void tegra_dma_free_chan_resources(struct dma_chan *dc)
>> @@ -1232,7 +1234,7 @@ static void tegra_dma_free_chan_resources(struct dma_chan *dc)
>>                 list_del(&sg_req->node);
>>                 kfree(sg_req);
>>         }
>> -       clk_disable_unprepare(tdma->dma_clk);
>> +       pm_runtime_put(tdma->dev);
>>
>>         tdc->slave_id = 0;
>>  }
>> @@ -1356,20 +1358,14 @@ static int tegra_dma_probe(struct platform_device *pdev)
>>         spin_lock_init(&tdma->global_lock);
>>
>>         pm_runtime_enable(&pdev->dev);
>> -       if (!pm_runtime_enabled(&pdev->dev)) {
>> +       if (!pm_runtime_enabled(&pdev->dev))
>>                 ret = tegra_dma_runtime_resume(&pdev->dev);
> 
> I didn't check, but does this bring device to powered on state?

Yes.

Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/