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

[Alistair Francis]

On Wed, Jul 21, 2021 at 6:26 AM Mark Brown <broonie@xxxxxxxxxx> wrote:
>
> 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.

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

>
> > 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.