Re: [PATCH v7 1/6] mfd: sy7636a: Initial commit

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]