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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 20 Jul 2021 21:26:39 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Alistair Francis <alistair@...stair23.me>, robh+dt@...nel.org,
        lgirdwood@...il.com, linux-imx@....com, kernel@...gutronix.de,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        alistair23@...il.com
Subject: Re: [PATCH v7 1/6] mfd: sy7636a: Initial commit

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)