Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp35538923rwd; Mon, 10 Jul 2023 08:51:13 -0700 (PDT) X-Google-Smtp-Source: APBJJlHg4IZtlXYpY+2Kbee6eVrkTnQA7AUhe+kgQSq059yO2/Oy+EFL/HkDSqVtX9Ob+YGdFjb9 X-Received: by 2002:a05:6358:5e0c:b0:133:84c:a085 with SMTP id q12-20020a0563585e0c00b00133084ca085mr11853272rwn.1.1689004272904; Mon, 10 Jul 2023 08:51:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689004272; cv=none; d=google.com; s=arc-20160816; b=lYTNq4zDmqns0gMPJZ3wGxRLxJ4xOkM1BQZ7UD50Okp/nEtvpukh1dRVyCCOwAefy1 7fFTKc9wgwSS2Y+oeu4QRVMSRnuWEz8RbvRVe9BuNw5Qp8igwbikqGB6IgqHazDZd3ha /nMZiaFy4X8nKC877Kk/mPDS4ugdwB8roDddp70EcmOyp77/QCB8zHn2NkS1rdcFy0VM SdRJjOYGm6uI4x6FY5taa90pKigjmeVbdPG54gX9HXG5JbcHVZ3Kkh6U42j5zebGNR4I h9AQUeYEw/o/S7bYMQL4SqyUndPOGi0MecXxVIZoh6IIE7qN9qcnTosPl/0nxVGvnQ5j QH6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=gPml+zrUwzq6ytakOhwGqZgwsKkdpl4p45LFguPE2cw=; fh=Fsr0prABRp6XB+9gHmfr+SzJ7Qh2Y9tLP/Xmw13+vF0=; b=wS2rQC7uLirXx7347L4SYPhBN6I8ohidgKdyhgf0TTqGP6DowAZbpXNpI4j4r3fddA J2eJjwGk6Vtf+fGZQfKZoir+U7XuNTj2p8grd89AIgsm2YALE1/c7i8L6CpDW4o21QIq HnNrdSbeM7e+2xEpfOY/jUSf6A7s6cEmx0EQDeXPuPA6TseFx5x0UYGsscutCFHdaWm1 cVmtlkNR3m2ylZh/ZWRZ7W/QQXel3c81rjHAwwE7pOi+iPoZTmbJldK780CflDvVAKjL QaOjtM7FS+rcguW1gi+fkfAgCjx+47hH2BPezJg8bgZ5N6q/RZPjGYQz594lJih1ccok XJQw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sntech.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a21-20020a63e855000000b00542b1792242si9581792pgk.720.2023.07.10.08.51.00; Mon, 10 Jul 2023 08:51:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sntech.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231173AbjGJPkc (ORCPT + 99 others); Mon, 10 Jul 2023 11:40:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44944 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229848AbjGJPkb (ORCPT ); Mon, 10 Jul 2023 11:40:31 -0400 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E58AD1; Mon, 10 Jul 2023 08:40:28 -0700 (PDT) Received: from i53875a50.versanet.de ([83.135.90.80] helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qIszV-0001o1-8T; Mon, 10 Jul 2023 17:39:57 +0200 From: Heiko Stuebner To: Mark Kettenis , robh+dt@kernel.org, conor+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org Cc: d3adme4t@gmail.com, macromorgan@hotmail.com, jbx6244@gmail.com, f.kardame@manjaro.org, amadeus@jmu.edu.cn, linux.amoon@gmail.com, aurelien@aurel32.net, anarsoul@gmail.com, wiagn233@outlook.com, frattaroli.nicolas@gmail.com, strit@manjaro.org, luiz.von.dentz@intel.com, zonyitoo@gmail.com, wens@csie.org, jensenhuang@friendlyarm.com, lasstp5011@gmail.com, frank-w@public-files.de, pgwipeout@gmail.com, leo@nabam.net, andyshrk@163.com, michael.riesch@wolfvision.net, jonas@kwiboo.se, festevam@denx.de, tobetter@gmail.com, jagan@amarulasolutions.com, cnsztl@gmail.com, cristian.ciocaltea@collabora.com, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, kernel@collabora.com Subject: Re: [PATCH] arm64: dts: rockchip: Drop invalid regulator-init-microvolt property Date: Mon, 10 Jul 2023 17:39:55 +0200 Message-ID: <4519023.cEBGB3zze1@phil> In-Reply-To: <87wmz7q1fr.fsf@bloch.sibelius.xs4all.nl> References: <20230707162217.675390-1-cristian.ciocaltea@collabora.com> <168899855919.1747213.9998138836668928892.b4-ty@sntech.de> <87wmz7q1fr.fsf@bloch.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS, T_SCC_BODY_TEXT_LINE,T_SPF_HELO_TEMPERROR autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Montag, 10. Juli 2023, 16:35:36 CEST schrieb Mark Kettenis: > > From: Heiko Stuebner > > Date: Mon, 10 Jul 2023 16:16:16 +0200 > > > > On Fri, 7 Jul 2023 19:22:17 +0300, Cristian Ciocaltea wrote: > > > The 'regulator-init-microvolt' property is not currently supported by > > > any driver, it was simply carried on from downstream kernels. > > > > > > The problem is also indicated by the following dtbs_check warning: > > > > > > rk3588-rock-5b.dtb: pmic@0: regulators:dcdc-reg4: Unevaluated properties are not allowed ('regulator-init-microvolt' was unexpected) > > > > > > [...] > > > > Applied, thanks! > > > > [1/1] arm64: dts: rockchip: Drop invalid regulator-init-microvolt property > > commit: 4d08b19629495b29601991d09d07865694c25199 > > This property *is used* by the drivers in U-Boot. Dropping this from > the Linux DTBs will likely result in broken boards the next time the > U-Boot DTBs are synched again from Linux. At least that is what > happened before... > > I think the right solution is to add this property to the DT binding > instead. I do have this vague memory of this coming up in the past, though don't remember what the resolution was then? Though it definitly doesn't look like the property was added to the binding in the meantime. Also I think that setting up initial regulator state would be (and seemingly is) for firmware to handle, so that property should instead be in the -uboot.dtsi. That DT isn't a configuration-space also is a decade long mantra. Heiko