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: <d2e1b1b3-20dd-4bfd-a67a-d43c5f488f7d@kernel.org>
Date: Fri, 5 Sep 2025 08:55:55 +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 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ