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
