linux-kernel - Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 1 Mar 2024 09:35:34 -0600
From: Rob Herring <robh@...nel.org>
To: Théo Lebrun <theo.lebrun@...tlin.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
	Guenter Roeck <linux@...ck-us.net>,
	Linus Walleij <linus.walleij@...aro.org>,
	Andi Shyti <andi.shyti@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	linux-arm-kernel@...ts.infradead.org, linux-i2c@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mips@...r.kernel.org,
	Gregory Clement <gregory.clement@...tlin.com>,
	Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	Tawfik Bayouk <tawfik.bayouk@...ileye.com>,
	Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org
Subject: Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon
 schema

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