Add 'clocks' property to enable QoS configuration. This property
enables the necessary clocks for QoS configuration.
QoS configuration is essential for ensuring that latency sensitive
components such as CPUs and multimedia engines receive prioritized
access to memory and interconnect resources. This helps to manage
bandwidth and latency across subsystems, improving system responsiveness
and performance in concurrent workloads.
Both 'reg' and 'clocks' properties are optional. If either is missing,
QoS configuration will be skipped. This behavior is controlled by the
'qos_requires_clocks' flag in the driver, which ensures that QoS
configuration is bypassed when required clocks are not defined.
Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
---
.../interconnect/qcom,qcs8300-rpmh.yaml | 53 ++++++++++++++++---
1 file changed, 47 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml
index e9f528d6d9a8..594e835d1845 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml
@@ -35,6 +35,10 @@ properties:
reg:
maxItems: 1
+ clocks:
+ minItems: 1
+ maxItems: 4
+
required:
- compatible
@@ -45,14 +49,39 @@ allOf:
compatible:
contains:
enum:
- - qcom,qcs8300-clk-virt
- - qcom,qcs8300-mc-virt
+ - qcom,qcs8300-aggre1-noc
then:
properties:
- reg: false
- else:
- required:
- - reg
+ clocks:
+ items:
+ - description: aggre UFS PHY AXI clock
+ - description: aggre QUP PRIM AXI clock
+ - description: aggre USB2 PRIM AXI clock
+ - description: aggre USB3 PRIM AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs8300-aggre2-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: RPMH CC IPA clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs8300-gem-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GCC DDRSS GPU AXI clock
unevaluatedProperties: false
@@ -63,6 +92,7 @@ examples:
reg = <0x9100000 0xf7080>;
#interconnect-cells = <2>;
qcom,bcm-voters = <&apps_bcm_voter>;
+ clocks = <&gcc_ddrss_gpu_axi_clk>;
};
clk_virt: interconnect-0 {
@@ -70,3 +100,14 @@ examples:
#interconnect-cells = <2>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
+
+ aggre1_noc: interconnect@16c0000 {
+ compatible = "qcom,qcs8300-aggre1-noc";
+ reg = <0x016c0000 0x17080>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ clocks = <&gcc_aggre_ufs_phy_axi_clk>,
+ <&gcc_aggre_noc_qupv3_axi_clk>,
+ <&gcc_aggre_usb2_prim_axi_clk>,
+ <&gcc_aggre_usb3_prim_axi_clk>;
+ };
--
2.17.1On Fri, Nov 28, 2025 at 08:31:04PM +0530, Odelu Kukatla wrote: > Add 'clocks' property to enable QoS configuration. This property > enables the necessary clocks for QoS configuration. > > QoS configuration is essential for ensuring that latency sensitive > components such as CPUs and multimedia engines receive prioritized > access to memory and interconnect resources. This helps to manage > bandwidth and latency across subsystems, improving system responsiveness > and performance in concurrent workloads. > > Both 'reg' and 'clocks' properties are optional. If either is missing, > QoS configuration will be skipped. This behavior is controlled by the > 'qos_requires_clocks' flag in the driver, which ensures that QoS > configuration is bypassed when required clocks are not defined. > > Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> > --- > .../interconnect/qcom,qcs8300-rpmh.yaml | 53 ++++++++++++++++--- > 1 file changed, 47 insertions(+), 6 deletions(-) As a generic feedback for Qualcomm interconnect drivers (please pass it through the team): Please ensure that QoS-related clocks are defined in the first driver submission. DT bindings should describe the hardware and it's not that the hardware has changed between the time the first patches were submitted and this patchset. I see a typical pattern that QoS support is being submitted several months later. Why is it so? Why can't QoS be a part of the _same_ patchset? -- With best wishes Dmitry
On 12/24/2025 1:25 AM, Dmitry Baryshkov wrote: > On Fri, Nov 28, 2025 at 08:31:04PM +0530, Odelu Kukatla wrote: >> Add 'clocks' property to enable QoS configuration. This property >> enables the necessary clocks for QoS configuration. >> >> QoS configuration is essential for ensuring that latency sensitive >> components such as CPUs and multimedia engines receive prioritized >> access to memory and interconnect resources. This helps to manage >> bandwidth and latency across subsystems, improving system responsiveness >> and performance in concurrent workloads. >> >> Both 'reg' and 'clocks' properties are optional. If either is missing, >> QoS configuration will be skipped. This behavior is controlled by the >> 'qos_requires_clocks' flag in the driver, which ensures that QoS >> configuration is bypassed when required clocks are not defined. >> >> Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> >> --- >> .../interconnect/qcom,qcs8300-rpmh.yaml | 53 ++++++++++++++++--- >> 1 file changed, 47 insertions(+), 6 deletions(-) > > As a generic feedback for Qualcomm interconnect drivers (please pass it > through the team): > > Please ensure that QoS-related clocks are defined in the first driver > submission. DT bindings should describe the hardware and it's not that > the hardware has changed between the time the first patches were > submitted and this patchset. > > I see a typical pattern that QoS support is being submitted several > months later. Why is it so? Why can't QoS be a part of the _same_ > patchset? > Hi Dmitry, Thanks for feedback. we are ensuring that QoS-related clocks are defined in the first driver submission like recently for Glymur/Kaanapali, there were part of first driver submission. QCS8300 and QCS615 are the only chip-sets, we are sending QoS patches separately. Thanks, Odelu
On 28/11/2025 16:01, Odelu Kukatla wrote: > Add 'clocks' property to enable QoS configuration. This property > enables the necessary clocks for QoS configuration. > > QoS configuration is essential for ensuring that latency sensitive > components such as CPUs and multimedia engines receive prioritized > access to memory and interconnect resources. This helps to manage > bandwidth and latency across subsystems, improving system responsiveness > and performance in concurrent workloads. Same problems with your previous and other commits: Please use subject prefixes matching the subsystem. You can get them for example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory your patch is touching. For bindings, the preferred subjects are explained here: https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters "on qcs8300" is redundant. Prefix defines that, so use proper prefixes. You do not add clocks for every interconnect... Best regards, Krzysztof
On 11/29/2025 3:15 PM, Krzysztof Kozlowski wrote: > On 28/11/2025 16:01, Odelu Kukatla wrote: >> Add 'clocks' property to enable QoS configuration. This property >> enables the necessary clocks for QoS configuration. >> >> QoS configuration is essential for ensuring that latency sensitive >> components such as CPUs and multimedia engines receive prioritized >> access to memory and interconnect resources. This helps to manage >> bandwidth and latency across subsystems, improving system responsiveness >> and performance in concurrent workloads. > > > Same problems with your previous and other commits: > > Please use subject prefixes matching the subsystem. You can get them for > example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory > your patch is touching. For bindings, the preferred subjects are > explained here: > https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters > > "on qcs8300" is redundant. Prefix defines that, so use proper prefixes. > You do not add clocks for every interconnect... > Thanks for the review and providing pointers, I’ll address the prefix issue in v2. > Best regards, > Krzysztof
On 28/11/2025 16:01, Odelu Kukatla wrote:
> Add 'clocks' property to enable QoS configuration. This property
> enables the necessary clocks for QoS configuration.
>
> QoS configuration is essential for ensuring that latency sensitive
> components such as CPUs and multimedia engines receive prioritized
> access to memory and interconnect resources. This helps to manage
> bandwidth and latency across subsystems, improving system responsiveness
> and performance in concurrent workloads.
I don't see how clocks property help here at all. Are you getting clock
rates in the driver of some other clocks to make QoS decisions?
>
> Both 'reg' and 'clocks' properties are optional. If either is missing,
No! They are not. How they can be optional in the hardware? How SoC can
have for ONE GIVEN device optional reg, meaning one board with the same
Soc has the IO address space but other board with the same SoC does not
have it.
> QoS configuration will be skipped. This behavior is controlled by the
> 'qos_requires_clocks' flag in the driver, which ensures that QoS
> configuration is bypassed when required clocks are not defined.
This suggests that - driver is not helping. Please describe the
hardware, not your drivers.
>
> Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
> ---
> .../interconnect/qcom,qcs8300-rpmh.yaml | 53 ++++++++++++++++---
> 1 file changed, 47 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml
> index e9f528d6d9a8..594e835d1845 100644
> --- a/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml
> +++ b/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml
> @@ -35,6 +35,10 @@ properties:
> reg:
> maxItems: 1
>
> + clocks:
> + minItems: 1
> + maxItems: 4
> +
> required:
> - compatible
>
> @@ -45,14 +49,39 @@ allOf:
> compatible:
> contains:
> enum:
> - - qcom,qcs8300-clk-virt
> - - qcom,qcs8300-mc-virt
> + - qcom,qcs8300-aggre1-noc
> then:
> properties:
> - reg: false
> - else:
> - required:
> - - reg
Why do you remove this? You cannot make random changes.
> + clocks:
> + items:
> + - description: aggre UFS PHY AXI clock
> + - description: aggre QUP PRIM AXI clock
> + - description: aggre USB2 PRIM AXI clock
> + - description: aggre USB3 PRIM AXI clock
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - qcom,qcs8300-aggre2-noc
> + then:
> + properties:
> + clocks:
> + items:
> + - description: RPMH CC IPA clock
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - qcom,qcs8300-gem-noc
> + then:
> + properties:
> + clocks:
> + items:
> + - description: GCC DDRSS GPU AXI clock
So all devices have clocks now? You made the schema less strict now,
removed pieces of it and you add more relaxed code telling every device
has a clock.
And none of this is explained in the commit msg.
>
> unevaluatedProperties: false
>
> @@ -63,6 +92,7 @@ examples:
> reg = <0x9100000 0xf7080>;
> #interconnect-cells = <2>;
> qcom,bcm-voters = <&apps_bcm_voter>;
> + clocks = <&gcc_ddrss_gpu_axi_clk>;
> };
>
> clk_virt: interconnect-0 {
> @@ -70,3 +100,14 @@ examples:
> #interconnect-cells = <2>;
> qcom,bcm-voters = <&apps_bcm_voter>;
> };
> +
> + aggre1_noc: interconnect@16c0000 {
No need for new example, it is the same as previous.
> + compatible = "qcom,qcs8300-aggre1-noc";
> + reg = <0x016c0000 0x17080>;
> + #interconnect-cells = <2>;
> + qcom,bcm-voters = <&apps_bcm_voter>;
> + clocks = <&gcc_aggre_ufs_phy_axi_clk>,
> + <&gcc_aggre_noc_qupv3_axi_clk>,
> + <&gcc_aggre_usb2_prim_axi_clk>,
> + <&gcc_aggre_usb3_prim_axi_clk>;
> + };
Best regards,
Krzysztof
On 11/29/2025 3:03 PM, Krzysztof Kozlowski wrote:
> On 28/11/2025 16:01, Odelu Kukatla wrote:
>> Add 'clocks' property to enable QoS configuration. This property
>> enables the necessary clocks for QoS configuration.
>>
>> QoS configuration is essential for ensuring that latency sensitive
>> components such as CPUs and multimedia engines receive prioritized
>> access to memory and interconnect resources. This helps to manage
>> bandwidth and latency across subsystems, improving system responsiveness
>> and performance in concurrent workloads.
>
> I don't see how clocks property help here at all. Are you getting clock
> rates in the driver of some other clocks to make QoS decisions?
>
We don't need to get clock rate/frequency, just need to enable the
clock(s) for QoS register access for which we need to get the clock
handle in driver.
>>
>> Both 'reg' and 'clocks' properties are optional. If either is missing,
>
> No! They are not. How they can be optional in the hardware? How SoC can
> have for ONE GIVEN device optional reg, meaning one board with the same
> Soc has the IO address space but other board with the same SoC does not
> have it.
>
I agree, I will drop the “optional” wording and rework the schema so
that `reg` and clocks’ are required for interconnects that implement
these resources, and not allowed for the NOCs without MMIO/clocks and
the virtual providers.
>> QoS configuration will be skipped. This behavior is controlled by the
>> 'qos_requires_clocks' flag in the driver, which ensures that QoS
>> configuration is bypassed when required clocks are not defined.
>
> This suggests that - driver is not helping. Please describe the
> hardware, not your drivers.
>
I will remove the driver related description from the commit message and
ensure the binding text stays strictly about the hardware.
>>
>> Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
>> ---
>> .../interconnect/qcom,qcs8300-rpmh.yaml | 53 ++++++++++++++++---
>> 1 file changed, 47 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml
>> index e9f528d6d9a8..594e835d1845 100644
>> --- a/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml
>> @@ -35,6 +35,10 @@ properties:
>> reg:
>> maxItems: 1
>>
>> + clocks:
>> + minItems: 1
>> + maxItems: 4
>> +
>> required:
>> - compatible
>>
>> @@ -45,14 +49,39 @@ allOf:
>> compatible:
>> contains:
>> enum:
>> - - qcom,qcs8300-clk-virt
>> - - qcom,qcs8300-mc-virt
>> + - qcom,qcs8300-aggre1-noc
>> then:
>> properties:
>> - reg: false
>> - else:
>> - required:
>> - - reg
>
> Why do you remove this? You cannot make random changes.
>
My goal was to add clocks for the interconnects that need them, not to
relax the `reg` requirements or change the behavior for
`clk-virt`/`mc-virt`. I will restore the previous `reg` handling and
only add additional constraints for `clocks` where they are actually
required by the hardware.
>> + clocks:
>> + items:
>> + - description: aggre UFS PHY AXI clock
>> + - description: aggre QUP PRIM AXI clock
>> + - description: aggre USB2 PRIM AXI clock
>> + - description: aggre USB3 PRIM AXI clock
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - qcom,qcs8300-aggre2-noc
>> + then:
>> + properties:
>> + clocks:
>> + items:
>> + - description: RPMH CC IPA clock
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - qcom,qcs8300-gem-noc
>> + then:
>> + properties:
>> + clocks:
>> + items:
>> + - description: GCC DDRSS GPU AXI clock
>
> So all devices have clocks now? You made the schema less strict now,
> removed pieces of it and you add more relaxed code telling every device
> has a clock.
>
Not all interconnects have clocks/MMIO, I will update the bindings as
you suggested in the fix:
https://lore.kernel.org/all/20251129094612.16838-2-krzysztof.kozlowski@oss.qualcomm.com/
> And none of this is explained in the commit msg.
>
>>
>> unevaluatedProperties: false
>>
>> @@ -63,6 +92,7 @@ examples:
>> reg = <0x9100000 0xf7080>;
>> #interconnect-cells = <2>;
>> qcom,bcm-voters = <&apps_bcm_voter>;
>> + clocks = <&gcc_ddrss_gpu_axi_clk>;
>> };
>>
>> clk_virt: interconnect-0 {
>> @@ -70,3 +100,14 @@ examples:
>> #interconnect-cells = <2>;
>> qcom,bcm-voters = <&apps_bcm_voter>;
>> };
>> +
>> + aggre1_noc: interconnect@16c0000 {
>
> No need for new example, it is the same as previous.
>
Understood. I will drop the additional example instead of duplicating
essentially the same content.
I’ll rework the patch accordingly and send a v2 that keeps the schema
strict.
>> + compatible = "qcom,qcs8300-aggre1-noc";
>> + reg = <0x016c0000 0x17080>;
>> + #interconnect-cells = <2>;
>> + qcom,bcm-voters = <&apps_bcm_voter>;
>> + clocks = <&gcc_aggre_ufs_phy_axi_clk>,
>> + <&gcc_aggre_noc_qupv3_axi_clk>,
>> + <&gcc_aggre_usb2_prim_axi_clk>,
>> + <&gcc_aggre_usb3_prim_axi_clk>;
>> + };
>
>
> Best regards,
> Krzysztof
On 22/12/2025 18:38, Odelu Kukatla wrote: > > > On 11/29/2025 3:03 PM, Krzysztof Kozlowski wrote: >> On 28/11/2025 16:01, Odelu Kukatla wrote: >>> Add 'clocks' property to enable QoS configuration. This property >>> enables the necessary clocks for QoS configuration. >>> >>> QoS configuration is essential for ensuring that latency sensitive >>> components such as CPUs and multimedia engines receive prioritized >>> access to memory and interconnect resources. This helps to manage >>> bandwidth and latency across subsystems, improving system responsiveness >>> and performance in concurrent workloads. >> >> I don't see how clocks property help here at all. Are you getting clock >> rates in the driver of some other clocks to make QoS decisions? >> > > We don't need to get clock rate/frequency, just need to enable the > clock(s) for QoS register access for which we need to get the clock > handle in driver. Not relevant what your driver does. Still getting clock does not improve system responsiveness. If you claim otherwise give me an argument or any sort of proof that providing clock has impact on system responsiveness. IOW, don't feed us marketing. It's waste of our time. > >>> >>> Both 'reg' and 'clocks' properties are optional. If either is missing, >> >> No! They are not. How they can be optional in the hardware? How SoC can >> have for ONE GIVEN device optional reg, meaning one board with the same >> Soc has the IO address space but other board with the same SoC does not >> have it. >> > > I agree, I will drop the “optional” wording and rework the schema so So why were they optional in the first place? What is this patch describing? Best regards, Krzysztof
On 12/23/2025 7:15 PM, Krzysztof Kozlowski wrote: > On 22/12/2025 18:38, Odelu Kukatla wrote: >> >> >> On 11/29/2025 3:03 PM, Krzysztof Kozlowski wrote: >>> On 28/11/2025 16:01, Odelu Kukatla wrote: >>>> Add 'clocks' property to enable QoS configuration. This property >>>> enables the necessary clocks for QoS configuration. >>>> >>>> QoS configuration is essential for ensuring that latency sensitive >>>> components such as CPUs and multimedia engines receive prioritized >>>> access to memory and interconnect resources. This helps to manage >>>> bandwidth and latency across subsystems, improving system responsiveness >>>> and performance in concurrent workloads. >>> >>> I don't see how clocks property help here at all. Are you getting clock >>> rates in the driver of some other clocks to make QoS decisions? >>> >> >> We don't need to get clock rate/frequency, just need to enable the >> clock(s) for QoS register access for which we need to get the clock >> handle in driver. > > Not relevant what your driver does. Still getting clock does not improve > system responsiveness. If you claim otherwise give me an argument or any > sort of proof that providing clock has impact on system responsiveness. > > IOW, don't feed us marketing. It's waste of our time. > > Hi Krzysztof, Thanks for the feedback. You are right that the clocks property itself does not improve system responsiveness. The QoS registers are inside a block whose interface is clock-gated, so the driver must enable the required clock before accessing those registers. The clocks property is only there to let the driver obtain that clock handle and enable the required clock; without that, the QoS registers are not accessible. The actual QoS behaviour is determined entirely by the values written to those registers, not by the presence of the clocks property in DT. About the “optional” wording: that was incorrect on my side. I will: 1.update the binding so that the `clocks` property accurately reflects the hardware and does not allow describing non-existing hardware, and 2.drop the “optional” wording and the performance oriented description from the commit message, keeping it to a minimal statement that the clock is needed to access the QoS registers. I’ll send a v2 with these changes. Best regards, Odelu > >> >>>> >>>> Both 'reg' and 'clocks' properties are optional. If either is missing, >>> >>> No! They are not. How they can be optional in the hardware? How SoC can >>> have for ONE GIVEN device optional reg, meaning one board with the same >>> Soc has the IO address space but other board with the same SoC does not >>> have it. >>> >> >> I agree, I will drop the “optional” wording and rework the schema so > > So why were they optional in the first place? What is this patch describing? > > > Best regards, > Krzysztof
On 29/11/2025 10:33, Krzysztof Kozlowski wrote: > On 28/11/2025 16:01, Odelu Kukatla wrote: >> Add 'clocks' property to enable QoS configuration. This property >> enables the necessary clocks for QoS configuration. >> >> QoS configuration is essential for ensuring that latency sensitive >> components such as CPUs and multimedia engines receive prioritized >> access to memory and interconnect resources. This helps to manage >> bandwidth and latency across subsystems, improving system responsiveness >> and performance in concurrent workloads. > > I don't see how clocks property help here at all. Are you getting clock > rates in the driver of some other clocks to make QoS decisions? > >> >> Both 'reg' and 'clocks' properties are optional. If either is missing, > > No! They are not. How they can be optional in the hardware? How SoC can > have for ONE GIVEN device optional reg, meaning one board with the same > Soc has the IO address space but other board with the same SoC does not > have it. > >> QoS configuration will be skipped. This behavior is controlled by the >> 'qos_requires_clocks' flag in the driver, which ensures that QoS >> configuration is bypassed when required clocks are not defined. > > This suggests that - driver is not helping. Please describe the > hardware, not your drivers. > And now I see you sent the same buggy code for sa8775p: https://lore.kernel.org/all/20251001073344.6599-2-odelu.kukatla@oss.qualcomm.com/ And this was already merged! No, you just make bindings worse. Best regards, Krzysztof
On Fri, 28 Nov 2025 20:31:04 +0530, Odelu Kukatla wrote: > Add 'clocks' property to enable QoS configuration. This property > enables the necessary clocks for QoS configuration. > > QoS configuration is essential for ensuring that latency sensitive > components such as CPUs and multimedia engines receive prioritized > access to memory and interconnect resources. This helps to manage > bandwidth and latency across subsystems, improving system responsiveness > and performance in concurrent workloads. > > Both 'reg' and 'clocks' properties are optional. If either is missing, > QoS configuration will be skipped. This behavior is controlled by the > 'qos_requires_clocks' flag in the driver, which ensures that QoS > configuration is bypassed when required clocks are not defined. > > Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> > --- > .../interconnect/qcom,qcs8300-rpmh.yaml | 53 ++++++++++++++++--- > 1 file changed, 47 insertions(+), 6 deletions(-) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/thermal/thermal-sensor.example.dtb: /example-0/soc/thermal-sensor@c263000: failed to match any schema with compatible: ['qcom,sdm845-tsens', 'qcom,tsens-v2'] Documentation/devicetree/bindings/thermal/thermal-sensor.example.dtb: /example-0/soc/thermal-sensor@c263000: failed to match any schema with compatible: ['qcom,sdm845-tsens', 'qcom,tsens-v2'] Documentation/devicetree/bindings/thermal/thermal-sensor.example.dtb: /example-0/soc/thermal-sensor@c265000: failed to match any schema with compatible: ['qcom,sdm845-tsens', 'qcom,tsens-v2'] Documentation/devicetree/bindings/thermal/thermal-sensor.example.dtb: /example-0/soc/thermal-sensor@c265000: failed to match any schema with compatible: ['qcom,sdm845-tsens', 'qcom,tsens-v2'] doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20251128150106.13849-2-odelu.kukatla@oss.qualcomm.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
© 2016 - 2026 Red Hat, Inc.