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: <92ca8288-3b57-0683-83fa-445e2be42086@nvidia.com>
Date:   Wed, 27 Feb 2019 11:47:00 +0530
From:   Sameer Pujar <spujar@...dia.com>
To:     Dmitry Osipenko <digetx@...il.com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>
CC:     <jhogan@...nel.org>, <thierry.reding@...il.com>,
        <jonathanh@...dia.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] ARM: tegra: enforce PM requirement


On 2/26/2019 10:22 PM, Dmitry Osipenko wrote:
> 26.02.2019 12:13, Russell King - ARM Linux admin пишет:
>> On Tue, Feb 26, 2019 at 01:55:37PM +0530, Sameer Pujar wrote:
>>> The requirement for this came while adding runtime PM support for HDA
>>> driver. There were concerns about driver explicitly handling !PM case.
>>> In general, drivers need to handle !PM case with work arounds for
>>> managing clocks and power explicitly, which is not really necessary
>>> when PM support on tegra is in good shape. In fact ARM 64-bit Tegra
>>> platforms enforce PM support and there is no reason why this cannot be
>>> done for 32-bit.
>>>
>>> More details with regards to above can be found in following patch,
>>> http://patchwork.ozlabs.org/patch/1036645/
>>>
>>> This patch selects PM unconditionally and drivers can rely on runtime
>>> PM framework for clock and power management.
>> What if the drivers are re-used on another SoC IP?  Doesn't this lead
>> to unexpected failures?
>>
>> If you want to do this, maybe also make those drivers depend on PM as
>> well?
> The commit message is inaccurate, it is intended for the Tegra HDA driver and not for some generic driver. The overall final intent is to remove dependency on the PM availability for all of Tegra drivers to "make Tegra maintainers life easier".
Wanted to convey that finally it would be the case for all Tegra 
drivers. I will update commit message to make it more clear.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ