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:
signature.asc
Description: PGP signature
