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.
