Messages in this thread | | | Date | Mon, 26 Sep 2022 07:59:08 +0100 | From | Lee Jones <> | Subject | Re: [PATCH v2 2/2] dt-bindings: regulator: Add bindings for Unisoc's SC2730 regulator |
| |
On Thu, 22 Sep 2022, Mark Brown wrote:
> On Thu, Sep 22, 2022 at 11:19:08AM +0100, Lee Jones wrote: > > On Thu, 22 Sep 2022, Chunyan Zhang wrote: > > > > I understand your point. But like I described previously [1], if we > > > still use the current solution (i.e. use devm_of_platform_populate() > > > to register MFD subdevices), a compatible string is required. I'm open > > > to switching to other solutions, do you have some suggestions? > > > > Many IPs encompassing multiple functions are described that way in > > DT. I don't have the details for *this* device to hand, so my > > comments here aren't specific to this use-case, but describing each > > function individually does describe the H/W accurately, which is all > > DT calls for. > > 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?
> > 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.
-- DEPRECATED: Please use lee@kernel.org
| |