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: <a9e0a8ff-e84e-4210-babd-0d0a1825e9ec@kernel.org>
Date: Tue, 25 Feb 2025 18:59:15 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Jeff Johnson <jeff.johnson@....qualcomm.com>,
 Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Jeff Johnson <jjohnson@...nel.org>, Bjorn Andersson
 <andersson@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 ath12k@...ts.infradead.org
Subject: Re: [PATCH] arm64: dts: qcom: x1e80100-slim7x: Drop incorrect
 qcom,ath12k-calibration-variant

On 25/02/2025 18:36, Jeff Johnson wrote:
> 
>>
>> Also post factum reasoning is not correct, because this would open the
>> gate to bypass any sort of review. Just squeeze your stuff into the DTS
>> and then you can bypass all DT maintainers :/
>>
>> All properties must be documented and bindings must be accepted *before*
>> DTS patch is applied.
> 
> There is no intention to bypass DT maintainers. We are just trying to upstream
> a large amount of downstream code, and in the process some pieces are coming

I don't see how this is related here - patch was not sent by anyone from
Qualcomm.

> out of order. And there is also confusion if binding, driver, and DTS changes
> should be in one series or three separate series.

How is it related to incorrect property here? It feels like this topic
is being hijacked for some other point. I am not happy with this because
then Bjorn will see that discussion is going so he will ignore the patch.

BTW, I gave my statement multiple times, writing bindings also mention
this, so is anything going to change if I say it 100th time here? In one
month there will be the same question :/

DTS must be applied via ARM SoC, thus you cannot combine DTS into
patchsets being entirely applied by driver subsystem maintainers (Greg,
netdev, sometimes maybe watchdog). For other maintainers, you can
combine it, because they know to skip DTS.

Bindings always go via subsystem, so they must be part of driver
patchset, unless of course there is no driver (but then bindings are
"the driver" patchset).


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ