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;
MIME-Version: 1.0
References: <20210708115804.212-1-alistair@alistair23.me> <YPbjZdu7T9wFcvNz@google.com>
 <20210720152351.GC5042@sirena.org.uk> <YPb1Hs0EoZ1MikuX@google.com> <20210720202639.GE5042@sirena.org.uk>
In-Reply-To: <20210720202639.GE5042@sirena.org.uk>
From:   Alistair Francis <alistair23@gmail.com>
Date:   Fri, 30 Jul 2021 16:21:18 +1000
Message-ID: <CAKmqyKNUBzWuLSvLTqaCNhDpuficctvCgpk3ZEBVFuKeCrx86w@mail.gmail.com>
Subject: Re: [PATCH v7 1/6] mfd: sy7636a: Initial commit
To:     Mark Brown <broonie@kernel.org>
Cc:     Lee Jones <lee.jones@linaro.org>,
        Alistair Francis <alistair@alistair23.me>,
        Rob Herring <robh+dt@kernel.org>, lgirdwood@gmail.com,
        dl-linux-imx <linux-imx@nxp.com>,
        Sascha Hauer <kernel@pengutronix.de>,
        devicetree <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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