Messages in this thread | | | Date | Wed, 28 Sep 2022 18:27:13 +0100 | From | Mark Brown <> | Subject | Re: [PATCH v2 2/2] dt-bindings: regulator: Add bindings for Unisoc's SC2730 regulator |
| |
On Mon, Sep 26, 2022 at 07:59:08AM +0100, Lee Jones wrote: > On Thu, 22 Sep 2022, Mark Brown wrote:
> > If people want to describe the individual regulators that'd be > > less of an issue, it's mainly when you're nesting what's > > effectively another MFD within a parent MFD that it's just noise > > that's being added to the DT.
> As I say, I haven't studied this use-case.
> These comments were designed to be more generic.
> What do you mean by nested MFDs?
Given that individual regulators tend to be separate physical IPs in the chip if you create a single device tree node that lumps them together you still need to also represent the individual regulators as well so that collection is functioning like a MFD does except not on a chip boundary.
> > > Can you imagine describing an SoC, which can be considered as a huge > > > MFD, with only a single node?
> > Honestly we should be arranging things so they're more like that, > > at least using overlays for the internals of the SoC so you don't > > have to rebuild the whole DT for updates to the SoC internals.
> Right, there would be one device root node. However each function; > clock providers, regulator controllers, PWMs, GPIOs, networking > (various), reset, watchdog, etc would have their own nodes. Rather > than attempting to describe everything in the parent's node.
We don't split things up by function, we split them up by IP - we don't just allocate a compatible for all the networking related functionality simply because there's a networking subsystem in Linux for example. [unhandled content-type:application/pgp-signature] | |