linux-kernel - Re: [PATCH v16 00/40] NVIDIA Tegra power management patches for 5.17

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, 16 Dec 2021 17:19:07 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Jonathan Hunter <jonathanh@...dia.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Viresh Kumar <vireshk@...nel.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Peter De Schrijver <pdeschrijver@...dia.com>,
        Mikko Perttunen <mperttunen@...dia.com>,
        Lee Jones <lee.jones@...aro.org>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
        Nishanth Menon <nm@...com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Michael Turquette <mturquette@...libre.com>,
        linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-pwm@...r.kernel.org,
        linux-mmc@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-clk@...r.kernel.org, David Heidelberg <david@...t.cz>
Subject: Re: [PATCH v16 00/40] NVIDIA Tegra power management patches for 5.17

16.12.2021 16:14, Thierry Reding пишет:
> On Wed, Dec 15, 2021 at 07:11:53PM +0300, Dmitry Osipenko wrote:
>> 15.12.2021 18:55, Thierry Reding пишет:
>>> On Wed, Dec 01, 2021 at 02:23:07AM +0300, Dmitry Osipenko wrote:
>>>> This series adds runtime PM support to Tegra drivers and enables core
>>>> voltage scaling for Tegra20/30 SoCs, resolving overheating troubles.
>>>>
>>>> All patches in this series are interdependent and should go via Tegra tree
>>>> for simplicity.
>>>
>>> So these can be applied in any order without breaking anything?
>>
>> Please notice that the word is *inter* dependent, not *in* dependent.
>>
>> There is a build dependency for the patches. The first two "soc/tegra"
>> must be applied first.
> 
> Okay, so I've separated the first two patches out into a separate stable
> branch that I can share between the Tegra and drm/tegra trees to pull in
> the build dependency and then I've applied the driver patches to those
> two trees and I've verified that the two branches build correctly. I've
> not done any runtime testing, but I'll trust you on that.

I only compile-tested VIC and NVDEC drivers, but they should be okay,
and thus, everything should be good.

>> The "soc/tegra: pmc: Enable core domain support for Tegra20 and Tegra30"
>> *must* be the last applied patch if we want to preserve bisectability.
>> The core voltage scaling can be enabled only once all the drivers got
>> the power management support.
>>
>> The rest could be applied out-of-order.
> 
> One last remaining question: I don't think I can apply that one patch if
> it requires that all the others are enabled first because it would
> basically create a circular dependency.
> 
> Can I pick up the final 7 patches (the DT ones) independently of that
> one patch without things breaking? If so, one option we could try is to
> wait for both Tegra and drm/tegra trees to get merged into v5.17-rc1 and
> then send that one patch (which is only a 4-line diff) right after
> v5.17-rc1 so that it makes it into v5.17-rc2. That avoids the circular
> dependency and should get everything enabled for v5.17.
> 
> Do you see any problems with that?
Deferring that one patch till v5.17-rc2 will work, thank you.