On Tue, Mar 26, 2024 at 07:29:17AM +0100, Krzysztof Kozlowski wrote:
On 26/03/2024 00:01, Nícolas F. R. A. Prado wrote:
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#validatin...
It's just "should"...
What is not clear there is what the reference point is: is it on linux-next? Mainline release?
Does it matter? There was never a new warning introduced by this patchset. The patchset itself is correct. No new warnings.
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).
I don't believe in such guarantees. Different maintainers apply patches differently, especially bindings, so this is beyond our control. Often also beyond SoC maintainer control.
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.
The most effective way is LKP-like or Rob's-bot-like automated replies to original email threads, by testing the original patchset on linux-next. But Rob's bot is actually doing it, just on different base.
Other reports, like for cases when only parts of patch is applied, could be also useful but I am afraid you will generate way too much of them. Binding is supposed to go via subsystem, DTS via SoC, so basically 90% of patchsets might have some sort of delays resulting in dtbs_check false positive warnings.
For my SoC I check my trees, mainline and next, and keep adding list of exceptions for expected issues. What's useful for Qualcomm? Konrad,
Is that list of exceptions in-tree? If there are known false-positives (issues that can't be "properly" fixed), they should be public knowledge. And if we all collaborate on such a list we can remove the noise from dtbs_check's output so it only contains real regressions and a backlog of issues that can be fixed.
Bjorn, any thoughts?
Have in mind that expected warnings can be for entire cycle when dealing with technical debt, because DTS goes N+1.
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
Yes and no. True regressions are not acceptable. Expected intermediate regressions as a result of patchset being applying, but not yet fully applied, are OK. Expected regressions for intra-cycle-work are also OK.
Got it. So I'll keep KernelCI running dtbs_check and tracking it, but I won't report failures caused by partially applied series.
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.
I invite therefore to my session: https://eoss24.sched.com/event/1aBEf?iframe=no We'll see if they keep growing :)
I won't be able to attend EOSS, but will catch the recording later ;)
Thanks, Nícolas