linux-kernel - Re: [PATCH] arm64: dts: qcom: x1e80100-slim7x: Drop incorrect qcom,ath12k-calibration-variant

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] [day] [month] [year] [list]

Message-ID: <5f21bb7f-b0f8-4b39-8afd-5a1a672c54ec@kernel.org>
Date: Tue, 25 Feb 2025 19:09:03 +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:59, Krzysztof Kozlowski wrote:
> 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 :/


Another BTW, not helpful to community, but if you asked above for
Qualcomm, that Qualcomm does not know where to post DTS, then you are
lucky, because your extensive internal guideline has it already very
clearly documented (detailed in "Driver upstreaming process" and a bit
in "feedback/review on lists"). The guide is quite comprehensive and
covers all typical cases, like that one.

Best regards,
Krzysztof