Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 25 Aug 2021 15:52:32 +0100
From:   Mark Brown <broonie@kernel.org>
To:     Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc:     Daniel Scally <djrscally@gmail.com>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Platform Driver <platform-driver-x86@vger.kernel.org>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Hans de Goede <hdegoede@redhat.com>,
        Mark Gross <mgross@linux.intel.com>,
        Maximilian Luz <luzmaximilian@gmail.com>,
        Kieran Bingham <kieran.bingham@ideasonboard.com>,
        Sakari Ailus <sakari.ailus@iki.fi>
Subject: Re: [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup_list
Message-ID: <20210825145232.GI5186@sirena.org.uk>
References: <20210824230620.1003828-1-djrscally@gmail.com>
 <20210824230620.1003828-2-djrscally@gmail.com>
 <20210825103301.GC5186@sirena.org.uk>
 <CAHp75VdHpjbjz4biTP11TKT6J+7WQi-a1Ru3VLuSxM5tSLCB3Q@mail.gmail.com>
 <20210825113013.GD5186@sirena.org.uk>
 <CAHp75VfKJgux8k_mPauYB3MHcEOcnnzhSpoUDi4mVFDgtmNXeg@mail.gmail.com>
 <20210825131139.GG5186@sirena.org.uk>
 <YSZMxxJ76vF316Pi@pendragon.ideasonboard.com>
 <4ac0acb9-83ea-7fcd-cde3-669ba3b699c6@gmail.com>
 <YSZSOZXxSac307/A@pendragon.ideasonboard.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="y96v7rNg6HAoELs5"
Content-Disposition: inline
In-Reply-To: <YSZSOZXxSac307/A@pendragon.ideasonboard.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


--y96v7rNg6HAoELs5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Aug 25, 2021 at 05:22:49PM +0300, Laurent Pinchart wrote:

> a very large number of regulators, it may not be too bad in practice. If
> I were to maintain the regulator subsystem I'd probably want a
> centralized implementation there, but that's certainly a personal
> preference, at least partly.

We already have some generic platform data for regulators so if it
doesn't want to define anything custom all a driver has to do is forward
that struct on to the core for handling, otherwise it just has to pick
the generic struct out of whatever custom thing it defines.

> On a side note, this RFC looks quite similar to what the GPIO subsystem
> does, which I personally consider nice as differences between regulator
> and GPIO in these areas are confusing for users.

My pushback here is that if all we're doing is providing a mechanism to
match platform data with firmware provided devices we shouldn't be
implementing it per API in the first place, we should have a generic
mechanism for system level quirking to pass platform data to devices
which works with anything - it could also absorb a lot of the DMI based
quirking we have in drivers already which boil down to using a DMI match
to pick some platform data.

--y96v7rNg6HAoELs5
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmEmWTAACgkQJNaLcl1U
h9DKXwf/dMpnjpe16heUgEu/y6oLmyrmLPbFe/hEtser4kVWV55hAdmKootw15AR
0LiCOkBmLTxd30GcAYCTgEsWOYOWDDZBITGDAgOiDNxSy0/lLGJm1FBOoo4H/Cx2
9bGJgDJ3BXdL2wvyJQbACfQKXatkbygpDS0R6oWehA0pe882YULckV8U2EpdmXUJ
G/yQA5TS5NAMok4ubxXoiW5Ey5ln5C/qgS/PEjnSj+XXLvYBMcgoW33jCstLEtfR
lIKTaR3jU5LoawQTerJjjwlxC8YIkWT4FO8nYNH5NSjUYRi2kOgkuTHV/gMxTILW
xmR40YYJ2abYC8Vs/BjaHfKw8fK6eA==
=JpfI
-----END PGP SIGNATURE-----

--y96v7rNg6HAoELs5--