From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6D2FC433F5 for ; Sun, 17 Apr 2022 20:56:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233258AbiDQU66 (ORCPT ); Sun, 17 Apr 2022 16:58:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235063AbiDQU6U (ORCPT ); Sun, 17 Apr 2022 16:58:20 -0400 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AFB7DD3; Sun, 17 Apr 2022 13:55:41 -0700 (PDT) Received: from [185.156.123.69] (helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ngBvh-0003OQ-Bj; Sun, 17 Apr 2022 22:55:33 +0200 From: Heiko Stuebner To: Peter Geis , Krzysztof Kozlowski Cc: Dongjin Kim , devicetree , arm-mail-list , "open list:ARM/Rockchip SoC..." , Linux Kernel Mailing List Subject: Re: [PATCH 2/2] arm64: dts: rockchip: Add Hardkernel ODROID-M1 board Date: Sun, 17 Apr 2022 22:55:25 +0200 Message-ID: <12089439.O9o76ZdvQC@phil> In-Reply-To: References: <20220329094446.415219-1-tobetter@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Am Sonntag, 17. April 2022, 19:45:52 CEST schrieb Krzysztof Kozlowski: > On 16/04/2022 14:07, Peter Geis wrote: > > >>> + dc_12v: dc-12v { > >> > >> Generic node name, so "regulator" or "regulator-0" > > > > Unfortunately, this advice breaks the regulator-fixed driver, which it > > seems cannot cope with a bunch of nodes all named "regulator". > > What exactly cannot cope? You cannot have different device nodes with > the same name but this is not a limitation of regulator but devicetree spec. > > > Setting the regulators as regulator-0 -1 -2 leads to fun issues where > > the regulator numbering in the kernel doesn't match the node numbers. > > There are no "node numbers"... maybe you mean unit addresses? But there > are none here. > > > It also makes it more fun when additional regulators need to be added > > and everything gets shuffled around. > > Usually adding - in subsequent DTS files - means increasing the numbers > so if you have regulator-[012] then just use regulator-[345] in other > files. I see potential mess when you combine several DTSI files, each > defining regulators, so in such case "some-name-regulator" (or reversed) > is also popular approach. so going with dc_12v: dc-12v-regulator { }; i.e. doing a some-name-regulator would be an in-spec way to go? In this case I would definitely prefer this over doing a numbered thing. I.e. regulator-0 can create really hard to debug issues, when you have another accidential regulator-0 for a different regulator in there, which then would create some sort of merged node. Heiko > > > If naming these uniquely to avoid confusion and collisions is such an > > issue, why is it not caught by make W=1 dtbs_check? > > Patches are welcome. :) > > Best regards, > Krzysztof >