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 0DAA5C433EF for ; Wed, 15 Jun 2022 19:12:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350133AbiFOTMn (ORCPT ); Wed, 15 Jun 2022 15:12:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345414AbiFOTMh (ORCPT ); Wed, 15 Jun 2022 15:12:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FAEC65E3; Wed, 15 Jun 2022 12:12:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2A88760BAF; Wed, 15 Jun 2022 19:12:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3635C34115; Wed, 15 Jun 2022 19:12:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655320355; bh=aBOcucEGYvvvWUKMiG7ck3GFTJH/y+rjo3oRAZKefCs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=L3qN7bWAFQSKXjkYhc9TwspKC2crGuSj7nyK7rS9UK1FSHsdpgcIogd/ldeF9WXP0 0KQuUQB2krRWqicXjNKySrPbr9t+einpWC6Tqmb+IOLPXNp1cphF1eXAUiXdrbZDhG pbL3HAmeqwMKoCe2WtSkfeUGfHFCqgoGbmKDjtlLyFqPQd6j9li2KYRPKGFlixyW37 LB8W56550jbrJnJH0+tXAWw+0xDH6ToBnw2WmjQEY70bvhRoe9HCL2V3jxORBWnEy3 okXzIdOXzKzFXiBg5yWMUVNRoufipEpnCTPBI/vlVVM114mRep+SDp6D1miBbqxqn6 TijqHGg7j1xsA== Date: Wed, 15 Jun 2022 20:12:26 +0100 From: Mark Brown To: Robin Murphy Cc: Marcel Ziswiler , "max.oss.09@gmail.com" , "krzysztof.kozlowski@linaro.org" , "geert@linux-m68k.org" , "linux-imx@nxp.com" , Francesco Dolcini , "robh@kernel.org" , "krzysztof.kozlowski+dt@linaro.org" , "ulf.hansson@linaro.org" , "linux-arm-kernel@lists.infradead.org" , "dmitry.baryshkov@linaro.org" , "biju.das.jz@bp.renesas.com" , "catalin.marinas@arm.com" , "geert+renesas@glider.be" , "bjorn.andersson@linaro.org" , "vkoul@kernel.org" , "shawnguo@kernel.org" , "kernel@pengutronix.de" , "khilman@kernel.org" , "s.hauer@pengutronix.de" , Andrejs Cainikovs , "will@kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rafael@kernel.org" , "festevam@gmail.com" , Max Krummenacher Subject: Re: [PATCH v1 0/5] power: domain: Add driver for a PM domain provider which controls Message-ID: References: <20220609150851.23084-1-max.oss.09@gmail.com> <20220613191549.GA4092455-robh@kernel.org> <12e3bb72-af2d-653f-b342-c6b4d6a1f292@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zB2UHw7muFO3meeO" Content-Disposition: inline In-Reply-To: X-Cookie: byob, v: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --zB2UHw7muFO3meeO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 15, 2022 at 07:24:50PM +0100, Robin Murphy wrote: > Multiple consumers sharing a voltage rail provided by a single regulator = is > so standard and well-supported that it barely seems worth pointing out, b= ut > for the avoidance of doubt I shall. Adding a new non-standard way to hide= a > specific subset of regulator functionality behind behind a magic driver > because it seems like slightly less work than handling it the well-known > established way sounds like a great recipe for technical debt and future > compatibility headaches. What if down the line you end up with a situation > where if device A is suspended, devices B and C are happy to save some po= wer > by running the "domain" at a lower voltage? Do we stubbornly start > duplicating more of the regulator framework in the magic power domain > driver, or is that the point where we have to switch all the consumers to > explicit supplies, and get to regret having "saved" that effort in the fi= rst > place... We also loose the runtime validation that the supplies being described in the DT correspond to the hardware in any meaningful way which would also make it harder to transition to explicit control of the supplies further down the line. =20 --zB2UHw7muFO3meeO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmKqLxkACgkQJNaLcl1U h9A8oQf/Qy+hNv0kHNOoFGSq8IZn9KhUnfZ1urDwa0BVgVd9o3gGVjfyGo2DRi4w C1+ssj8EA61LDsquEBRULVokHyU9usYmXKfRJRHweArlWyZvbxoHvRfgk+kjCBhZ A/VYrv2LvZHpYzrAVeviYllJs+ZGCq2Y1wMw8cFP558j8z2o5tEAFMdbpJRJvPNy WeFvgrixx2yNQr0VgkCWr/RJ+vCY+80hgrhEWvJj6wEtIpGRqgoYbDw6LM9EU4Gu hmSPorQNZbFBVQ8Dk597Ffq90RK8Y9axZGn1FvqXx07s2CYdS/wn1QiZLWdrLOf8 vpJIHU0pSsKo+plFfCiboC9PItlMLw== =ratS -----END PGP SIGNATURE----- --zB2UHw7muFO3meeO--