linux-kernel - Re: [PATCH v4 2/8] dt-bindings: ufs: qcom: Add SC7180 compatible string

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: <9dcca70b-2c34-4b5b-8b8a-18bd9b4e6e5b@linaro.org>
Date: Wed, 14 Feb 2024 09:56:00 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Rob Herring <robh@...nel.org>,
 Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: David Wronek <davidwronek@...il.com>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konrad.dybcio@...aro.org>,
 Herbert Xu <herbert@...dor.apana.org.au>,
 "David S. Miller" <davem@...emloft.net>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
 Alim Akhtar <alim.akhtar@...sung.com>, Avri Altman <avri.altman@....com>,
 Bart Van Assche <bvanassche@....org>, Andy Gross <agross@...nel.org>,
 Vinod Koul <vkoul@...nel.org>, Kishon Vijay Abraham I <kishon@...nel.org>,
 cros-qcom-dts-watchers@...omium.org, linux-arm-msm@...r.kernel.org,
 linux-crypto@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
 linux-phy@...ts.infradead.org, ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH v4 2/8] dt-bindings: ufs: qcom: Add SC7180 compatible
 string

On 13/02/2024 19:11, Rob Herring wrote:
> On Tue, Feb 13, 2024 at 4:30 AM Dmitry Baryshkov
> <dmitry.baryshkov@...aro.org> wrote:
>>
>> On Tue, 13 Feb 2024 at 00:22, Rob Herring <robh@...nel.org> wrote:
>>>
>>> On Sun, Jan 21, 2024 at 05:57:42PM +0100, David Wronek wrote:
>>>> Document the compatible for the UFS found on SC7180.
>>>>
>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>>> Signed-off-by: David Wronek <davidwronek@...il.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>
>>> Should have been picked up by SCSI/UFS maintainers, but it
>>> hasn't, so I applied it.
>>
>> And it now triggers schema warnings, because sc7180-ufshc has 7 clocks
>> and 1 reg entries.
> 
> And now dropped... Perhaps the dts changes should be too.
> 
> Maybe QCom maintainers should require a report of dtbs_check on new
> boards. My comparisons of Linus vs. next warnings often show an
> increase in QCom warnings. Like right now:
> 
> linus: arch/arm64/boot/dts/qcom:1990:265
> next: arch/arm64/boot/dts/qcom:1610:298

I was tracking new dtbs_check warnings on Qualcomm for selected
subsystems and for selected boards, but that grew faster than I was able
to fix it so I gave up...

After all these months and all these review feedbacks many people still
do not test their DTS with dtbs_check, so maybe the solution is to start
dropping people's patches? Detect new warnings and drop the patch from
Qualcomm tree?

> 
> First number is total warnings. Second number is unique warnings
> (stripping dtb name). Some of this is just mismatch between schemas
> and dts changes showing up in next, but it doesn't tend to go to 0 as
> the merge window approaches. I've seen this several cycles. All the
> data is available from my CI jobs, and I regularly look at the diff
> with this:
> 
> $ less ~/bin/gl-diff-dtb-warnings
> #!/bin/sh
> 
> [ -z "$1" ] && { echo "Missing arch!"; exit 1; }
> 
> arch="$1"
> 
> job="job-dtbs-check"
> logfile="platform-warnings.log"
> 
> # url <branch> <arch>
> url() {
>         local branch="$1"
>         local arch="$2"
>         echo "https://gitlab.com/robherring/linux-dt/-/jobs/artifacts/${branch}/raw/${logfile}?job=${job}%3A+%5B${arch}%5D"
> 
> }
> 
> curl -Ls -o orig.log $(url linus ${arch})
> curl -Ls -o next.log $(url next ${arch})
> meld orig.log next.log

That's useful, thanks!

Best regards,
Krzysztof