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 X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80E98C11F66 for ; Tue, 13 Jul 2021 18:19:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 63FBA613AB for ; Tue, 13 Jul 2021 18:19:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234163AbhGMSWF (ORCPT ); Tue, 13 Jul 2021 14:22:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:33374 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229478AbhGMSWE (ORCPT ); Tue, 13 Jul 2021 14:22:04 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 984E06136D; Tue, 13 Jul 2021 18:19:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626200354; bh=cMdO8+EgP81LfDfTGGuhCMJIV2cTg8n2Vt2uLKZKQvY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AYagHoxmuuhdYYALTMy0Q2QzsYQKQo64SCjxbrQFNSmccdgFZZYj5FhbCWle8irZ4 ZX3aK0KibU+ac/zl9UoKgsz2NM5X1E3JxiO7AenjX7Jn94Zk2gV96yi8DLX0C8jpgE wRtfjCW1lnWQrIvGmGqc31NrCAqW6SNAfcB77sqq0dV3d1J6QLwI/b1LAKmHzgMh9O +sVCiQHKSKl2NgahMzCbjgoUv5Yql6QfkcUbbNDSqmLU0J0efFDeiltdUT3Nz8iUh8 pyKdo6GXMgPySplfafVMb7+DDVzrEuwRFI2kj0gTxoxpBsYJlgPqXQa9eYNbsf29W+ 1CLKwFhM5PgZQ== Date: Tue, 13 Jul 2021 19:18:37 +0100 From: Mark Brown To: Andy Shevchenko Cc: Daniel Scally , Linux Kernel Mailing List , Platform Driver , Hans de Goede , Mark Gross , Maximilian Luz , Liam Girdwood , Laurent Pinchart , kieran.bingham@ideasonboard.com Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework Message-ID: <20210713181837.GE4098@sirena.org.uk> References: <20210709170426.GC4112@sirena.org.uk> <20210712124223.GB4435@sirena.org.uk> <20210712133428.GD4435@sirena.org.uk> <20210712170120.GG4435@sirena.org.uk> <20210713152454.GC4098@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k3qmt+ucFURmlhDS" Content-Disposition: inline In-Reply-To: X-Cookie: Keep away from fire or flame. User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --k3qmt+ucFURmlhDS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 13, 2021 at 06:55:59PM +0300, Andy Shevchenko wrote: > On Tue, Jul 13, 2021 at 6:25 PM Mark Brown wrote: > > The driver code is trivial boilerplate, assuming someone doesn't go and > > implement a helper to register stuff separately like I suggested. The > > proposed swnode stuff would involve duplicating the DT parsing code. > > This seems like a whole lot of effort for something that provides a > > worse result than either of the existing things. > I'm not sure I follow. Where did you see the duplication when I saw > the other way around? The current patch consists entirely of additions, it does not remove any existing code at all, the diffstat is: 5 files changed, 174 insertions(+) > Converting code from OF to fwnode APIs in most cases is smooth and > doesn't add any overhead to the codebase, We explicitly do not want to attempt to parse regulator properties out of ACPI platform descriptions because using the regulator binding on ACPI platforms conflicts with the ACPI model for power management and we really don't want to encourage platforms to attempt to mix and match here, it's not going to lead to anything robust. System integrators that need this sort of OS visible low level power management really should be working with the UEFI forum to get an ACPI specification for it, or if they don't really need it fixing up their AML to DTRT. If you were to say that we could bodge around that by somehow forcing this binding to exist only for swnodes when running on ACPI systems then we'd still have the problems with creating something with worse tooling than what's there already. Like I said in the other mail fwnode is a nice hack for systems that are using ACPI but have hardware that's doing something totally outside the ACPI model to allow them to reuse work that's been done for DT, it's not a universal solution to the lack of appropriate support for describing modern systems in ACPI. --k3qmt+ucFURmlhDS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmDt2PwACgkQJNaLcl1U h9AIYggAhPNHiBwlKUk6c+lvxWX8ALjqQ6kBBP2KDmwrMIuFZsvdXTXhHUQ1vPkb w7PG6FcToLxXp/CBQlzstZ9A6UP992Bd750Amcwy/ewXy4iI0EDrxsfcVmFYIonv KPs1YEint4jWFqG2RshAqI47K1HFFlIMVMdg/ml/RS86ZKYbJ69IzJ0swPfD0yZo zQ5fmFAStFmy16NRb6TdzWgU3fhulaKZsNrNXAvc7yNK4kuoE5OPfxl+oth46L6k T3uE9qCP3uTF3IWQLTjdWIvRUpe1fKtkvhedS9BQvgluaECF+bilchTHDkl/oERO FAXsZvvu/qRAoXEzYBTezPTelH3/BA== =wdNf -----END PGP SIGNATURE----- --k3qmt+ucFURmlhDS--