From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5820C1C33; Fri, 1 Mar 2024 15:35:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709307337; cv=none; b=HYkW9tvIcbqFZFLiKrSZ0z3C1kA26cJPstC3FQKeLhVTLmJziB+JWugXjnNsUoebQ8Pn+D0vdYjCJZV0ffZixSTc6sKsPnbYAIVMGwQzgt7k+H6TM6zSkMhbrIuNwrFgbIjZfVCNK1ltvj4gzIpJ6YQ0e8vvswPkWUwa5PYk4NY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709307337; c=relaxed/simple; bh=M529ZWz6bYFuuGmZpJLVgAUP6VgulNwbi5i3qlbkET4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rX0V9E+/WFlwn3EBFGHWXMkqp5ESxYSW3FJhOGq/4bVNrMADBKSvPVO0hZ+w/oFKf30ZOFVyU1hkaof923DHe/S8VHKs9OrTVdrv87AP3/l2w6lN3RCaIm+310C7LzJpew2ba+QHR241EsYAWXyMP0mkxzBTJxKBry2iwQCUDEo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=engGmUkK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="engGmUkK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86BCEC433F1; Fri, 1 Mar 2024 15:35:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709307336; bh=M529ZWz6bYFuuGmZpJLVgAUP6VgulNwbi5i3qlbkET4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=engGmUkK3+QyCySd6cnHaoesNC4acJ3alTWL9hkST6hCVPUk6jx/wdlKLPnA4dMRT OqgQzVn2cxNbgjzrGxAzAM/G0Q2U5mSCnX3cGzzAVKPSaiMbwnp1at/ewtulAVi49k IOUSLAAoFtHhpXnpOFM32Zwv0bf6pVapLzd+1FoCRLxcWj/btjhW4rkXK++PVGaxDr QuhaFLQjLZyhXcaeREGlxgBfChASmuIy0TcoVAva9mfGQpPYYVWwaWR+QNYavWPNKJ 7dm7RcciMFp14LYGpnir5lb59cHkkeJV2ctLTiy+VzUVkJoykR1TWNtyzE/IvoGg9H OTZ4wZV2OigtQ== Date: Fri, 1 Mar 2024 09:35:34 -0600 From: Rob Herring To: =?iso-8859-1?Q?Th=E9o?= Lebrun Cc: Krzysztof Kozlowski , Guenter Roeck , Linus Walleij , Andi Shyti , Krzysztof Kozlowski , Conor Dooley , Thomas Bogendoerfer , linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, Gregory Clement , Vladimir Kondratiev , Thomas Petazzoni , Tawfik Bayouk , Jean Delvare , linux-hwmon@vger.kernel.org Subject: Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema Message-ID: <20240301153534.GA2144041-robh@kernel.org> References: <20240229-mbly-i2c-v2-0-b32ed18c098c@bootlin.com> <20240229-mbly-i2c-v2-2-b32ed18c098c@bootlin.com> <6749c8df-c545-4aca-bc18-4dfe9c9f15b0@linaro.org> Precedence: bulk X-Mailing-List: linux-mips@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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