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: <CALHNRZ-iGASiVknUFJXJ8OkYYrG+0VMTistreDAG38WytHmEPQ@mail.gmail.com>
Date: Thu, 4 Sep 2025 12:49:37 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
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 Thu, Sep 4, 2025 at 3:19 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> 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?

The only relevant snippet I see is:
"The Documentation/ portion of the patch should come in the series
before the code implementing the binding."

I had got it in my head that all bindings should go first as a
separate subsystem, not just docs. I will double check all series
before sending new revisions.

Aaron