| Message ID | 20240308-topic-rb1_lmh-v2-0-bac3914b0fe3@linaro.org |
|---|---|
| Headers | show |
| Series | QCM2290 LMH | expand |
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
On 26/03/2024 15:07, Nícolas F. R. A. Prado wrote: >> 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 None of the warnings - C, sparse, smatch, coccinelle, Coverity, dtc, dtbs_check - are stored in-tree. I don't think dtbs_check should be here exception, because all these warnings can be fixed - it's just a matter of effort. ARM64 Exynos is warning free since a year. ARM Exynos similarly, but with one undocumented compatible and few bumps due to intra-cycle DTS changes. > that can't be "properly" fixed), they should be public knowledge. And if we all They are "public": https://github.com/krzk/tools/blob/master/buildbot/master_build_common.py#L26 but I don't know how to make them public and usable knowledge. Best regards, Krzysztof
Wire up LMH on QCM2290 and fix a bad bug while at it. P1-2 for thermal, P3 for qcom Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> --- Changes in v2: - Pick up tags - Fix a couple typos in commit messages - Drop stray msm8998 binding addition - Link to v1: https://lore.kernel.org/r/20240308-topic-rb1_lmh-v1-0-50c60ffe1130@linaro.org --- Konrad Dybcio (2): dt-bindings: thermal: lmh: Add QCM2290 compatible thermal: qcom: lmh: Check for SCM availability at probe 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(-) --- base-commit: 8ffc8b1bbd505e27e2c8439d326b6059c906c9dd change-id: 20240308-topic-rb1_lmh-1e0f440c392a Best regards,