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]
Date: Mon, 25 Mar 2024 20:59:55 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: NĂ­colas F. R. A. Prado <nfraprado@...labora.com>,
 Konrad Dybcio <konrad.dybcio@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 Daniel Lezcano <daniel.lezcano@...aro.org>, Zhang Rui <rui.zhang@...el.com>,
 Lukasz Luba <lukasz.luba@....com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Thara Gopinath
 <thara.gopinath@...il.com>, Amit Kucheria <amitk@...nel.org>,
 Marijn Suijten <marijn.suijten@...ainline.org>,
 linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, stable@...r.kernel.org,
 Loic Poulain <loic.poulain@...aro.org>
Subject: Re: [PATCH v2 0/3] QCM2290 LMH

On 20/03/2024 20:08, NĂ­colas F. R. A. Prado wrote:
>> Loic Poulain (1):
>>       arm64: dts: qcom: qcm2290: Add LMH node
>>
>>  Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 12 ++++++++----
>>  arch/arm64/boot/dts/qcom/qcm2290.dtsi                   | 14 +++++++++++++-
>>  drivers/thermal/qcom/lmh.c                              |  3 +++
>>  3 files changed, 24 insertions(+), 5 deletions(-)
> 
> Hi,
> 
> I've started tracking the results of 'make dtbs_check' on linux-next, and I've
> noticed that on today's next, next-20240320, there's a new warning coming from
> this. The reason is that the DT change has landed, but the binding has not,
> since it goes through a separate tree. I thought the binding was supposed to
> always land before the driver and DT that make use of it, but looking through

There is no such rule. Of course new binding should be documented in
earlier or the same kernel release cycle as users get in, but it's not a
requirement.


> the dt-binding documentation pages I couldn't find anything confirming or
> denying that.
> 
> I expect this to happen again in the future, which is why I'm reaching out to
> understand better how to deal with this kind of situation.

Deal as what to do? Are you asking in terms of maintenance of some
subsystem or sending some patches? In this particular case here, I don't
think there is anything on your side to deal with.

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ