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 45DAFC07E96 for ; Tue, 13 Jul 2021 15:25:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2EE606128D for ; Tue, 13 Jul 2021 15:25:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237041AbhGMP2V (ORCPT ); Tue, 13 Jul 2021 11:28:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:38412 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236932AbhGMP2U (ORCPT ); Tue, 13 Jul 2021 11:28:20 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B3FEF610A6; Tue, 13 Jul 2021 15:25:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626189930; bh=slvo4++D/WMUD87+IeDa43+rMSUdJ7pRafi0OFuXKRU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VCJxFjmHhOD5YoNcRXzYS2oNmiXBNNahYLUY4Pn2TntSnoUAt9Em1DEIWIKH9Cyx4 DBH6WzVUyfSPtOOJzlJrietcQejisg2yIaM/wGQL12Q3ZKcZbR40ywGNuvrsPR5tAb LoWw1aT8x3swe0ewJfoC5AunhgBLWuED7nT+QeqSIH05Kwt2HZ/dErrf3qiNn01lDs DjHpA57nR8nyk8NvolcPIsXvSqK2QuwwR7gsV78vbUKwowcltBC2AW5fX3EVxYQN3J Kn8GI2fTLveGRViAwITWW2jKJBdHJeOKyPMIlpmLcIx/QBR1Q6AHFsXgjEYlhudEbp EPIyPDHEcFIrA== Date: Tue, 13 Jul 2021 16:24:54 +0100 From: Mark Brown To: Daniel Scally Cc: Andy Shevchenko , 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: <20210713152454.GC4098@sirena.org.uk> References: <20210708224226.457224-1-djrscally@gmail.com> <20210709170426.GC4112@sirena.org.uk> <20210712124223.GB4435@sirena.org.uk> <20210712133428.GD4435@sirena.org.uk> <20210712170120.GG4435@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WplhKdTI2c8ulnbP" 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 --WplhKdTI2c8ulnbP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 13, 2021 at 12:32:26AM +0100, Daniel Scally wrote: > I do think it can simplify driver code too; a lot of them aren't written > to parse platform data to get the init data, as they're just relying on > reading it from devicetree so in the event that we get more cases like > this, we need to modify those drivers to look for platform data too. On > the other hand, even the drivers that don't directly call > of_get_regulator_init_data() still do that lookup during the > regulator_of_get_init_data() call in regulator_register(), so the ones > that do parse platform data for init_data structs will check DT as part > of regulator_register() anyway. Imitating that seems simpler to me. 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. > It also creates some problems to suppress the enumeration of the i2c > device via ACPI (which we'll have to do in a machine specific fashion, > because some laptops have this chip with properly configured ACPI and To be clear I think that's a terrible idea. > > down to being another data table, I imagine you could write a helper for > > it, or probably even come up with some generic thing that let you > > register a platform data/DMI combo independently of the driver to get it > > out of the driver code (looking more like the existing GPIO code which > > is already being used in another bit of this quirking). > The advantage of the GPIO lookups is there's no need to have the pointer > to the registered devices to register the lookup table; we could imitate > that, by adding entries to a list with the lookup values being device > and regulator name (with the init data as the thing that's "looked up") > and check for those during regulator_register() maybe? Like I keep saying I think that's a much better approach than trying to use swnodes, they just seem like a terrible fit for the problem. --WplhKdTI2c8ulnbP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmDtsEUACgkQJNaLcl1U h9BvuAf9FSesJj6q2adc0w2TQHj3Zun/eu+tdZJc4E3Qv0B/Trmy1Ude28JSR9ZR wJO2zKMFracVEMutZVH2I08d1F9zfZ/DpNtTsDMVrPBmG3Lt3O9lZDqbwg3KrLNY fNR8SV9X3gyZJETNdZcEpQNA/9uubj+AEf5HBeaw4uDtytb+VfBRq7vOAf1H8XAs I9+ai5xpHW4Yj32NxRD4y8/LP0aVrp4Av1NVCJJ47InK3X2R8zzvz5x1YVu/py19 Yn8Z/Pvmc3ZB+QmzET6pKe8/Ro08Rf+Oj+jsDDN4HDLeo8jCsQ/brNb1v2WNHeC2 0IHQ0n5DOcI3pozkKDJIFN0hJTJ7Aw== =KjyV -----END PGP SIGNATURE----- --WplhKdTI2c8ulnbP--