[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YyxKSjMPlGPfegpJ@sirena.org.uk>
Date: Thu, 22 Sep 2022 12:43:06 +0100
From: Mark Brown <broonie@...nel.org>
To: Lee Jones <lee.jones@...aro.org>
Cc: Chunyan Zhang <zhang.lyra@...il.com>,
Liam Girdwood <lgirdwood@...il.com>,
Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
Baolin Wang <baolin.wang7@...il.com>,
Orson Zhai <orsonzhai@...il.com>,
Chunyan Zhang <chunyan.zhang@...soc.com>,
LKML <linux-kernel@...r.kernel.org>, Lee Jones <lee@...nel.org>
Subject: Re: [PATCH v2 2/2] dt-bindings: regulator: Add bindings for Unisoc's
SC2730 regulator
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.
> 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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists