Reference common hwmon schema which has the generic "label" property,
parsed by Linux hwmon subsystem.
To: Jean Delvare <[email protected]>
To: Guenter Roeck <[email protected]>
Cc: [email protected]
Signed-off-by: Théo Lebrun <[email protected]>
---
Documentation/devicetree/bindings/hwmon/lm75.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml b/Documentation/devicetree/bindings/hwmon/lm75.yaml
index ed269e428a3d..29bd7460cc26 100644
--- a/Documentation/devicetree/bindings/hwmon/lm75.yaml
+++ b/Documentation/devicetree/bindings/hwmon/lm75.yaml
@@ -57,6 +57,7 @@ required:
- reg
allOf:
+ - $ref: hwmon-common.yaml#
- if:
not:
properties:
@@ -71,7 +72,7 @@ allOf:
properties:
interrupts: false
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
--
2.44.0
On Thu, 29 Feb 2024 19:10:50 +0100, Théo Lebrun wrote:
> Reference common hwmon schema which has the generic "label" property,
> parsed by Linux hwmon subsystem.
>
> To: Jean Delvare <[email protected]>
> To: Guenter Roeck <[email protected]>
> Cc: [email protected]
> Signed-off-by: Théo Lebrun <[email protected]>
> ---
> Documentation/devicetree/bindings/hwmon/lm75.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/lm75.yaml:
Error in referenced schema matching $id: http://devicetree.org/schemas/hwmon/hwmon-common.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/lm75.example.dtb: sensor@48: False schema does not allow {'compatible': ['st,stlm75'], 'reg': [[72]], 'vs-supply': [[4294967295]], '$nodename': ['sensor@48']}
from schema $id: http://devicetree.org/schemas/hwmon/lm75.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/lm75.example.dtb: temperature-sensor@48: False schema does not allow {'compatible': ['ams,as6200'], 'reg': [[72]], 'vs-supply': [[4294967295]], 'interrupts': [[17, 3]], '$nodename': ['temperature-sensor@48']}
from schema $id: http://devicetree.org/schemas/hwmon/lm75.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/[email protected]
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.
On 29/02/2024 19:10, Théo Lebrun wrote:
> Reference common hwmon schema which has the generic "label" property,
> parsed by Linux hwmon subsystem.
>
Please do not mix independent patchsets. You create unneeded
dependencies blocking this patch. This patch depends on hwmon work, so
it cannot go through different tree.
If you insist to combine independent patches, then at least clearly
express merging strategy or dependency in patch changelog --- .
> To: Jean Delvare <[email protected]>
> To: Guenter Roeck <[email protected]>
> Cc: [email protected]
> Signed-off-by: Théo Lebrun <[email protected]>
> ---
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> On 29/02/2024 19:10, Théo Lebrun wrote:
>> Reference common hwmon schema which has the generic "label" property,
>> parsed by Linux hwmon subsystem.
>>
>
> Please do not mix independent patchsets. You create unneeded
> dependencies blocking this patch. This patch depends on hwmon work, so
> it cannot go through different tree.
>
> If you insist to combine independent patches, then at least clearly
> express merging strategy or dependency in patch changelog --- .
>
For my part I have to say that I don't know what to do with it.
Rob's robot reported errors, so I won't apply it, and I don't
feel comfortable giving it an ack either because of those errors.
Guenter
>
>> To: Jean Delvare <[email protected]>
>> To: Guenter Roeck <[email protected]>
>> Cc: [email protected]
>> Signed-off-by: Théo Lebrun <[email protected]>
>> ---
>
>
> Reviewed-by: Krzysztof Kozlowski <[email protected]>
>
> Best regards,
> Krzysztof
>
Hello,
On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> > On 29/02/2024 19:10, Théo Lebrun wrote:
> >> Reference common hwmon schema which has the generic "label" property,
> >> parsed by Linux hwmon subsystem.
> >>
> >
> > Please do not mix independent patchsets. You create unneeded
> > dependencies blocking this patch. This patch depends on hwmon work, so
> > it cannot go through different tree.
I had to pick between this or dtbs_check failing on my DTS that uses a
label on temperature-sensor@48.
> > If you insist to combine independent patches, then at least clearly
> > express merging strategy or dependency in patch changelog --- .
I do not know how such indirect conflicts are usually resolved. Hwmon
can take it but MIPS might want to also take it to have valid DTS.
Any advice?
> For my part I have to say that I don't know what to do with it.
> Rob's robot reported errors, so I won't apply it, and I don't
> feel comfortable giving it an ack either because of those errors.
Can reproduce the error when patch "dt-bindings: hwmon: add common
properties" is not applied. Cannot reproduce when patch is applied.
Commit d590900b62f0 on hwmon-next. Cannot reproduce with hwmon-next as
parent.
Regards,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On 01/03/2024 10:41, Théo Lebrun wrote:
> Hello,
>
> On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
>> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
>>> On 29/02/2024 19:10, Théo Lebrun wrote:
>>>> Reference common hwmon schema which has the generic "label" property,
>>>> parsed by Linux hwmon subsystem.
>>>>
>>>
>>> Please do not mix independent patchsets. You create unneeded
>>> dependencies blocking this patch. This patch depends on hwmon work, so
>>> it cannot go through different tree.
>
> I had to pick between this or dtbs_check failing on my DTS that uses a
> label on temperature-sensor@48.
I don't see how is that relevant. You can organize your branches as you
wish, e.g. base one b4 branch on another and you will not have any warnings.
>
>>> If you insist to combine independent patches, then at least clearly
>>> express merging strategy or dependency in patch changelog --- .
>
> I do not know how such indirect conflicts are usually resolved. Hwmon
> can take it but MIPS might want to also take it to have valid DTS.
>
> Any advice?
I don't see any conflict.
>
>> For my part I have to say that I don't know what to do with it.
>> Rob's robot reported errors, so I won't apply it, and I don't
>> feel comfortable giving it an ack either because of those errors.
>
> Can reproduce the error when patch "dt-bindings: hwmon: add common
> properties" is not applied. Cannot reproduce when patch is applied.
> Commit d590900b62f0 on hwmon-next. Cannot reproduce with hwmon-next as
> parent.
Yeah, but we see the error reported and it means something is missing.
Best regards,
Krzysztof
Hello,
On Fri Mar 1, 2024 at 11:13 AM CET, Krzysztof Kozlowski wrote:
> On 01/03/2024 10:41, Théo Lebrun wrote:
> > Hello,
> >
> > On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
> >> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> >>> On 29/02/2024 19:10, Théo Lebrun wrote:
> >>>> Reference common hwmon schema which has the generic "label" property,
> >>>> parsed by Linux hwmon subsystem.
> >>>>
> >>>
> >>> Please do not mix independent patchsets. You create unneeded
> >>> dependencies blocking this patch. This patch depends on hwmon work, so
> >>> it cannot go through different tree.
> >
> > I had to pick between this or dtbs_check failing on my DTS that uses a
> > label on temperature-sensor@48.
>
> I don't see how is that relevant. You can organize your branches as you
> wish, e.g. base one b4 branch on another and you will not have any warnings.
That is what I do, I however do not want mips-next to have errors when
running dtbs_check. Having dtbs_check return errors is not an issue?
> >>> If you insist to combine independent patches, then at least clearly
> >>> express merging strategy or dependency in patch changelog --- .
> >
> > I do not know how such indirect conflicts are usually resolved. Hwmon
> > can take it but MIPS might want to also take it to have valid DTS.
> >
> > Any advice?
>
> I don't see any conflict.
I shouldn't have called that a conflict, more like a dependency.
> >> For my part I have to say that I don't know what to do with it.
> >> Rob's robot reported errors, so I won't apply it, and I don't
> >> feel comfortable giving it an ack either because of those errors.
> >
> > Can reproduce the error when patch "dt-bindings: hwmon: add common
> > properties" is not applied. Cannot reproduce when patch is applied.
> > Commit d590900b62f0 on hwmon-next. Cannot reproduce with hwmon-next as
> > parent.
>
> Yeah, but we see the error reported and it means something is missing.
Yes, this series depends on "dt-bindings: hwmon: add common properties"
which the bot doesn't know it needs to apply.
Should I submit this patch independently and have my DTS be broken wrt
dtbs_check?
Have a nice day,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On 01/03/2024 11:44, Théo Lebrun wrote:
> Hello,
>
> On Fri Mar 1, 2024 at 11:13 AM CET, Krzysztof Kozlowski wrote:
>> On 01/03/2024 10:41, Théo Lebrun wrote:
>>> Hello,
>>>
>>> On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
>>>> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
>>>>> On 29/02/2024 19:10, Théo Lebrun wrote:
>>>>>> Reference common hwmon schema which has the generic "label" property,
>>>>>> parsed by Linux hwmon subsystem.
>>>>>>
>>>>>
>>>>> Please do not mix independent patchsets. You create unneeded
>>>>> dependencies blocking this patch. This patch depends on hwmon work, so
>>>>> it cannot go through different tree.
>>>
>>> I had to pick between this or dtbs_check failing on my DTS that uses a
>>> label on temperature-sensor@48.
>>
>> I don't see how is that relevant. You can organize your branches as you
>> wish, e.g. base one b4 branch on another and you will not have any warnings.
>
> That is what I do, I however do not want mips-next to have errors when
> running dtbs_check. Having dtbs_check return errors is not an issue?
You should ask your maintainer, but I don't understand how this is
achievable anyway. Subsystem bindings *should not* go via MIPS-next, so
how are you going to solve this?
And why MIPS shall be different than all other ARM/RISC-V SoCs?
Best regards,
Krzysztof
Hello,
On Fri Mar 1, 2024 at 12:35 PM CET, Krzysztof Kozlowski wrote:
> On 01/03/2024 11:44, Théo Lebrun wrote:
> > On Fri Mar 1, 2024 at 11:13 AM CET, Krzysztof Kozlowski wrote:
> >> On 01/03/2024 10:41, Théo Lebrun wrote:
> >>> On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
> >>>> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> >>>>> On 29/02/2024 19:10, Théo Lebrun wrote:
> >>>>>> Reference common hwmon schema which has the generic "label" property,
> >>>>>> parsed by Linux hwmon subsystem.
> >>>>>
> >>>>> Please do not mix independent patchsets. You create unneeded
> >>>>> dependencies blocking this patch. This patch depends on hwmon work, so
> >>>>> it cannot go through different tree.
> >>>
> >>> I had to pick between this or dtbs_check failing on my DTS that uses a
> >>> label on temperature-sensor@48.
> >>
> >> I don't see how is that relevant. You can organize your branches as you
> >> wish, e.g. base one b4 branch on another and you will not have any warnings.
> >
> > That is what I do, I however do not want mips-next to have errors when
> > running dtbs_check. Having dtbs_check return errors is not an issue?
>
> You should ask your maintainer, but I don't understand how this is
> achievable anyway. Subsystem bindings *should not* go via MIPS-next, so
> how are you going to solve this?
I thought it'd go in hwmon-next and be picked up by mips-next as well.
It's clear now that the right approach is to send the lm75.yaml patch
alone.
I'll wait some more before sending a new revision that drops this
lm75.yaml patch.
Have a nice day,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On 01/03/2024 15:09, Théo Lebrun wrote:
>>>> I don't see how is that relevant. You can organize your branches as you
>>>> wish, e.g. base one b4 branch on another and you will not have any warnings.
>>>
>>> That is what I do, I however do not want mips-next to have errors when
>>> running dtbs_check. Having dtbs_check return errors is not an issue?
>>
>> You should ask your maintainer, but I don't understand how this is
>> achievable anyway. Subsystem bindings *should not* go via MIPS-next, so
>> how are you going to solve this?
>
> I thought it'd go in hwmon-next and be picked up by mips-next as well.
> It's clear now that the right approach is to send the lm75.yaml patch
> alone.
Then mips-next-dts branch would be based on subsystem branch with driver
changes? That violates the policy of not creating dependencies between
DTS and drivers.
What matters is final or even future release, not intermediate state.
Best regards,
Krzysztof
On Fri, Mar 01, 2024 at 11:44:37AM +0100, Th?o Lebrun wrote:
> Hello,
>
> On Fri Mar 1, 2024 at 11:13 AM CET, Krzysztof Kozlowski wrote:
> > On 01/03/2024 10:41, Th?o Lebrun wrote:
> > > Hello,
> > >
> > > On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
> > >> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> > >>> On 29/02/2024 19:10, Th?o Lebrun wrote:
> > >>>> Reference common hwmon schema which has the generic "label" property,
> > >>>> parsed by Linux hwmon subsystem.
> > >>>>
> > >>>
> > >>> Please do not mix independent patchsets. You create unneeded
> > >>> dependencies blocking this patch. This patch depends on hwmon work, so
> > >>> it cannot go through different tree.
> > >
> > > I had to pick between this or dtbs_check failing on my DTS that uses a
> > > label on temperature-sensor@48.
> >
> > I don't see how is that relevant. You can organize your branches as you
> > wish, e.g. base one b4 branch on another and you will not have any warnings.
>
> That is what I do, I however do not want mips-next to have errors when
> running dtbs_check. Having dtbs_check return errors is not an issue?
That's a good goal, but difficult to achieve as you can see. Given
dtbs_check in general has tons of warnings already, we currently don't
worry about more warnings in specific branches. We just look at mainline
and linux-next. And for that it's still so many, I'm just looking at
general trends. It runs daily here[1].
As we get more platforms trying to stay at zero warnings, then we'll
need to revisit this. I imagine that will mean all schemas have to go in
1 branch with acks from subsystem maintainers. That's the opposite of
what we do now. And then .dts branches will have to merge in the schema
branch as needed. There are some checks (make dt_compatible_check) to
for drivers vs. the schemas, so we'd have the same issue with
intermittent warnings. But the drivers should be more decoupled from the
schemas than the dts files.
Rob
[1] https://gitlab.com/robherring/linux-dt/-/jobs
On Thu, Feb 29, 2024 at 10:53:07PM -0800, Guenter Roeck wrote:
> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> > On 29/02/2024 19:10, Th?o Lebrun wrote:
> > > Reference common hwmon schema which has the generic "label" property,
> > > parsed by Linux hwmon subsystem.
> > >
> >
> > Please do not mix independent patchsets. You create unneeded
> > dependencies blocking this patch. This patch depends on hwmon work, so
> > it cannot go through different tree.
> >
> > If you insist to combine independent patches, then at least clearly
> > express merging strategy or dependency in patch changelog --- .
> >
>
> For my part I have to say that I don't know what to do with it.
> Rob's robot reported errors, so I won't apply it, and I don't
> feel comfortable giving it an ack either because of those errors.
You can apply it. Those are just related to not finding
hwmon-common.yaml which you have, and Th?o confirmed it works on
hwmon-next.
Rob
Hello,
On Fri Mar 1, 2024 at 4:35 PM CET, Rob Herring wrote:
> On Fri, Mar 01, 2024 at 11:44:37AM +0100, Théo Lebrun wrote:
> > Hello,
> >
> > On Fri Mar 1, 2024 at 11:13 AM CET, Krzysztof Kozlowski wrote:
> > > On 01/03/2024 10:41, Théo Lebrun wrote:
> > > > Hello,
> > > >
> > > > On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
> > > >> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> > > >>> On 29/02/2024 19:10, Théo Lebrun wrote:
> > > >>>> Reference common hwmon schema which has the generic "label" property,
> > > >>>> parsed by Linux hwmon subsystem.
> > > >>>>
> > > >>>
> > > >>> Please do not mix independent patchsets. You create unneeded
> > > >>> dependencies blocking this patch. This patch depends on hwmon work, so
> > > >>> it cannot go through different tree.
> > > >
> > > > I had to pick between this or dtbs_check failing on my DTS that uses a
> > > > label on temperature-sensor@48.
> > >
> > > I don't see how is that relevant. You can organize your branches as you
> > > wish, e.g. base one b4 branch on another and you will not have any warnings.
> >
> > That is what I do, I however do not want mips-next to have errors when
> > running dtbs_check. Having dtbs_check return errors is not an issue?
>
> That's a good goal, but difficult to achieve as you can see. Given
> dtbs_check in general has tons of warnings already, we currently don't
> worry about more warnings in specific branches. We just look at mainline
> and linux-next. And for that it's still so many, I'm just looking at
> general trends. It runs daily here[1].
Here's my opportunity to ask a question I've had for a while: do you
have a way to filter out dtbs that are known to be bad actors (ie have
many many warnings)? Maybe a list of platforms you talk about below
that aim at zero warnings?
Another way to ask this: what would be a good default DT_SCHEMA_FILES
value? Not filtering leads to way too many errors.
Regards,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On Thu, Feb 29, 2024 at 07:10:50PM +0100, Th?o Lebrun wrote:
> Reference common hwmon schema which has the generic "label" property,
> parsed by Linux hwmon subsystem.
>
> To: Jean Delvare <[email protected]>
> To: Guenter Roeck <[email protected]>
> Cc: [email protected]
> Signed-off-by: Th?o Lebrun <[email protected]>
> Reviewed-by: Krzysztof Kozlowski <[email protected]>
Applied to hwmon-next.
Thanks,
Guenter