linux-kernel - Re: [PATCH 0/8] Support dynamic EMC frequency scaling on Tegra186/Tegra194

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: <08062eb7-1b7d-4fc3-86ea-af70069065eb@kernel.org>
Date: Thu, 4 Sep 2025 10:19:29 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Aaron Kling <webgeek1234@...il.com>
Cc: Rob Herring <robh@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 Thierry Reding <thierry.reding@...il.com>,
 Jonathan Hunter <jonathanh@...dia.com>, "Rafael J. Wysocki"
 <rafael@...nel.org>, Viresh Kumar <viresh.kumar@...aro.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, linux-tegra@...r.kernel.org,
 linux-pm@...r.kernel.org
Subject: Re: [PATCH 0/8] Support dynamic EMC frequency scaling on
 Tegra186/Tegra194

On 03/09/2025 08:37, Aaron Kling wrote:
> On Wed, Sep 3, 2025 at 1:20 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>
>> On 02/09/2025 18:51, Aaron Kling wrote:
>>> On Tue, Sep 2, 2025 at 3:23 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>>>
>>>> On Sun, Aug 31, 2025 at 10:33:48PM -0500, Aaron Kling wrote:
>>>>> This series borrows the concept used on Tegra234 to scale EMC based on
>>>>> CPU frequency and applies it to Tegra186 and Tegra194. Except that the
>>>>> bpmp on those archs does not support bandwidth manager, so the scaling
>>>>> iteself is handled similar to how Tegra124 currently works.
>>>>>
>>>>
>>>> Three different subsystems and no single explanation of dependencies and
>>>> how this can be merged.
>>>
>>> The only cross-subsystem hard dependency is that patches 5 and 6 need
>>> patches 1 and 2 respectively. Patch 5 logically needs patch 3 to
>>> operate as expected, but there should not be compile compile or probe
>>> failures if those are out of order. How would you expect this to be
>>> presented in a cover letter?
>>
>> Also, placing cpufreq patch between two memory controller patches means
>> you really make it more difficult to apply it for the maintainers.
>> Really, think thoroughly how this patchset is supposed to be read.
> 
> This is making me more confused. My understanding was that a series
> like this that has binding, driver, and dt changes would flow like
> that: all bindings first, all driver changes in the middle, and all dt

You mix completely independent subsystems, that's the main problem.
Don't send v3 before you understand it or we finish the discussion here.

> changes last. Are you suggesting that this should be: cpufreq driver
> -> bindings -> memory drivers -> dt? Are the bindings supposed to be
> pulled with the driver changes? I had understood those to be managed
> separately.
What does the submitting patches doc in DT say?

Best regards,
Krzysztof