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]
Message-ID: <20240301153534.GA2144041-robh@kernel.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ