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:   Tue, 20 Jul 2021 21:26:39 +0100
From:   Mark Brown <broonie@kernel.org>
To:     Lee Jones <lee.jones@linaro.org>
Cc:     Alistair Francis <alistair@alistair23.me>, robh+dt@kernel.org,
        lgirdwood@gmail.com, linux-imx@nxp.com, kernel@pengutronix.de,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        alistair23@gmail.com
Subject: Re: [PATCH v7 1/6] mfd: sy7636a: Initial commit
Message-ID: <20210720202639.GE5042@sirena.org.uk>
References: <20210708115804.212-1-alistair@alistair23.me>
 <YPbjZdu7T9wFcvNz@google.com>
 <20210720152351.GC5042@sirena.org.uk>
 <YPb1Hs0EoZ1MikuX@google.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="h56sxpGKRmy85csR"
Content-Disposition: inline
In-Reply-To: <YPb1Hs0EoZ1MikuX@google.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


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

On Tue, Jul 20, 2021 at 05:09:02PM +0100, Lee Jones wrote:
> On Tue, 20 Jul 2021, Mark Brown wrote:

> > At least the regulator probably shouldn't be - this is just a Linux
> > specific grouping of devices, it's not really directly a block in the
> > hardware in a way that's platform independent.

> I've seen (and authored) regulator support in DT before.

> What's changed?  They're controlled by registers, right?

Nothing's changed, I routinely push back on regulator drivers that have
a compatible string for a MFD subfunction like this.  I do miss them
sometimes but try not to.

> Is the problem that the registers are usually split?

It's just not really describing the hardware, it's encoding the way
Linux splits things up into the DT that adds no descriptive information.
We're not getting any information about where the IPs are in the device
or anything from the compatible, and typically it's describing a set of
disjoint IPs with minimal overlap in their configuration.  If it's a
binding for something like an individual LDO or DCDC and we've got
multiple instances of that within a single chip then it starts to get
more useful but that's not what something like this is doing.  We're not
gaining anything by putting a compatible string in there, all it does is
make the DT bigger and add some ABI.

Similar issues exist with CODEC subfunctions - those are usually
describing huge piles of different IPs but we happen to want to pull
them together for Linux, typically including some clocking which if we
were going down to the level of describing components of the MFD in the
DT should be being described using their own bindings.

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

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

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmD3MX4ACgkQJNaLcl1U
h9BumAf9Gv7JxuM4KnEtvd75CvzJ6Q1mpDe/o2nSUZ28ZpkUWzFjSPKcuZVP4QMr
6pfKO7WafBbuYEsF5Cqm8foXG3mf657HcvH7Gh8S5YAt2edtHFEyf1NI/CxpV0pd
oCT1KyHMfVCmPtU5Y1c1qpD1FrAQqP7LBlQCSbsbLgKNmNXCwT81p4Byn+FzGK0Y
GGoETC8N9/5X26ypFwmCFRgtwYv5YUHJNp3fgfg5AfPc/Ylq1I0FkUweVWWBaZtm
9BBe9iiGzTgQvHwYUT8YVfsgBh2fVuTGoBMHLB6hkQURTPGTPU9t906w1YIu/HU4
Q15zJ/pjolZ+BE6CO4hDx1Z0s9qPgQ==
=Ul11
-----END PGP SIGNATURE-----

--h56sxpGKRmy85csR--