Received-SPF: pass (google.com: domain of linux-kernel+bounces-118148-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Mon, 25 Mar 2024 19:01:55 -0400
From: =?utf-8?B?TsOtY29sYXMgRi4gUi4gQS4=?= Prado <nfraprado@collabora.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Konrad Dybcio <konrad.dybcio@linaro.org>,
	Bjorn Andersson <andersson@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Zhang Rui <rui.zhang@intel.com>, Lukasz Luba <lukasz.luba@arm.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Thara Gopinath <thara.gopinath@gmail.com>,
	Amit Kucheria <amitk@kernel.org>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	stable@vger.kernel.org, Loic Poulain <loic.poulain@linaro.org>
Subject: Re: [PATCH v2 0/3] QCM2290 LMH
Message-ID: <8e0cc005-0b3a-4475-bfe4-82ec46d918a5@notapiano>
References: <20240308-topic-rb1_lmh-v2-0-bac3914b0fe3@linaro.org>
 <d8ed4e6c-549f-4c04-b38a-2d788df8b707@notapiano>
 <dbe90a1c-bac2-4176-8eba-7ad96a182313@linaro.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <dbe90a1c-bac2-4176-8eba-7ad96a182313@linaro.org>

On Mon, Mar 25, 2024 at 08:59:55PM +0100, Krzysztof Kozlowski wrote:
> 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.

So, after giving the documentation a second look, I found this:

"For new platforms, or additions to existing ones, make dtbs_check should not
add any new warnings."

Source: https://www.kernel.org/doc/html/latest/process/maintainer-soc.html#validating-devicetree-files

What is not clear there is what the reference point is: is it on linux-next?
Mainline release?

As Konrad pointed out it's tricky (and maybe not worth it) to guarantee this for
linux-next. But for mainline release it seems feasible (and IMO the target, as
after that stability guarantees should apply).

> 
> 
> > 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.

I'm asking what's the most helpful way to you the maintainers for me to report
these failures in the future.

Rob has already automated running dtbs_check for patches coming into the mailing
list. And I have set up KernelCI to run dtbs_check on linux-next in order to
catch any issues that might slip through, or happen during integration of the
trees, etc. 

Now, if we agree that dtbs_check regressions on linux-next are acceptable, at
least ones like this, where the issue is just synchronization between
maintainers, then I can simply not report them in the future. But we should
have some point where dtbs_check should not regress, and mainline release seems
the reasonable choice, because if we don't then dtbs_check warnings would just
keep growing forever.

Thanks,
N?colas