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

On Wed, Jul 21, 2021 at 6:26 AM Mark Brown [off-list ref] wrote:

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

quoted

On Tue, 20 Jul 2021, Mark Brown wrote:

quoted

quoted

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.

quoted

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

quoted

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.

Sorry, I just want to clarify what I should do.

Are you saying that I shouldn't add the regulator to the device tree?
Should I leave it as part of `sy7636a_cells` then?

Alistair

quoted

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.