lkml.org 
[lkml]   [2022]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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]
\
 
 \ /
  Last update: 2022-09-28 19:28    [W:0.054 / U:0.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site