Thread (27 messages) 27 messages, 5 authors, 2025-09-09

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

From: Krzysztof Kozlowski <krzk@kernel.org>
Date: 2025-09-05 06:56:00
Also in: linux-pm, linux-tegra, lkml

On 04/09/2025 19:49, Aaron Kling wrote:
quoted
quoted
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.
A bit further because you asked about process:

3) For a series going though multiple trees, the binding patch should be
kept with the driver using the binding.

We do like this since years, and git log would tell you who committed
the bindings (driver maintainer), so I really do not understand why 1%
of cases happening other way caused that impression from your last sentence.

Best regards,
Krzysztof
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help