devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Aaron Kling <webgeek1234@gmail.com>
Cc: Rob Herring <robh@kernel.org>, Conor Dooley <conor+dt@kernel.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH 0/8] Support dynamic EMC frequency scaling on Tegra186/Tegra194
Date: Fri, 5 Sep 2025 08:55:55 +0200	[thread overview]
Message-ID: <d2e1b1b3-20dd-4bfd-a67a-d43c5f488f7d@kernel.org> (raw)
In-Reply-To: <CALHNRZ-iGASiVknUFJXJ8OkYYrG+0VMTistreDAG38WytHmEPQ@mail.gmail.com>

On 04/09/2025 19:49, Aaron Kling wrote:
>>
>>> 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

  reply	other threads:[~2025-09-05  6:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-01  3:33 [PATCH 0/8] Support dynamic EMC frequency scaling on Tegra186/Tegra194 Aaron Kling via B4 Relay
2025-09-01  3:33 ` [PATCH 1/8] dt-bindings: tegra: Add ICC IDs for dummy memory clients for Tegra186 Aaron Kling via B4 Relay
2025-09-01  3:33 ` [PATCH 2/8] dt-bindings: tegra: Add ICC IDs for dummy memory clients for Tegra194 Aaron Kling via B4 Relay
2025-09-02  8:25   ` Krzysztof Kozlowski
2025-09-02 16:57     ` Aaron Kling
2025-09-01  3:33 ` [PATCH 3/8] cpufreq: tegra186: add OPP support and set bandwidth Aaron Kling via B4 Relay
2025-09-01  5:53   ` Viresh Kumar
2025-09-02 17:21     ` Aaron Kling
2025-09-03  5:01       ` Viresh Kumar
2025-09-04 11:19         ` Sumit Gupta
2025-09-01  3:33 ` [PATCH 4/8] memory: tegra186-emc: Support non-bpmp icc scaling Aaron Kling via B4 Relay
2025-09-01  3:33 ` [PATCH 5/8] memory: tegra186: Support " Aaron Kling via B4 Relay
2025-09-01  3:33 ` [PATCH 6/8] memory: tegra194: " Aaron Kling via B4 Relay
2025-09-01  3:33 ` [PATCH 7/8] arm64: tegra: Add CPU OPP tables for Tegra186 Aaron Kling via B4 Relay
2025-09-01  3:33 ` [PATCH 8/8] arm64: tegra: Add CPU OPP tables for Tegra194 Aaron Kling via B4 Relay
2025-09-02  8:23 ` [PATCH 0/8] Support dynamic EMC frequency scaling on Tegra186/Tegra194 Krzysztof Kozlowski
2025-09-02 16:51   ` Aaron Kling
2025-09-03  6:18     ` Krzysztof Kozlowski
2025-09-03  6:20     ` Krzysztof Kozlowski
2025-09-03  6:37       ` Aaron Kling
2025-09-04  8:19         ` Krzysztof Kozlowski
2025-09-04 17:49           ` Aaron Kling
2025-09-05  6:55             ` Krzysztof Kozlowski [this message]
2025-09-04 11:47 ` Sumit Gupta
2025-09-04 16:47   ` Aaron Kling
2025-09-05 13:37     ` Sumit Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d2e1b1b3-20dd-4bfd-a67a-d43c5f488f7d@kernel.org \
    --to=krzk@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=viresh.kumar@linaro.org \
    --cc=webgeek1234@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).