Re: DT Query on "New Compatible vs New Property"

[Sudeep Holla <sudeep.holla@arm.com>]

On Wed, Apr 10, 2024 at 09:55:24AM -0700, Nikunj Kela wrote:
> 
> On 3/19/2024 9:13 AM, Sudeep Holla wrote:
> > On Tue, Mar 19, 2024 at 03:41:40PM +0000, Srinivas Kandagatla wrote:
> > > On 19/03/2024 15:17, Sudeep Holla wrote:
> > > > I am not debating on the implementation just to be clear. I accept changes
> > > > might be needed there. The $subject is all about DT bindings and what need
> > > > to be changes and for me nothing, just use existing bindings and if there
> > > > are issues there, let us discuss it with specifics.
> > > > 
> > > How can changes to dt bindings be nothing? All the resources
> > > clk/regulators/resets will become optional and a new power or perf domain
> > > will become required for each device with firmwares that support SCMI Perf.
> > > 
> > Correct, sorry to miss the point that few properties are now optional from
> > mandatory before. Very good point. I was so caught up with the addition of
> > the new "firmware controlled blah blah" property/compatible that I missed
> > to observe mandatory->optional as a change. Thanks for correcting me.
> > 
> If there are no more questions on this and everyone is on the same page, I
> would like to conclude this thread in favor of using a new DT property
> 'qcom,firmware-managed-resources'.
>

This is exactly opposite to what I have advocated so far in this thread.
Not sure how you drew to this conclusion. Check [1] and [2] for example.
The point was not to have qcom specific compatibles or properties as it
doesn't scale well. Please chime into those if you have argument and how
you came to this conclusion.

--
Regards,
Sudeep

[1] https://lore.kernel.org/all/ZfMZ9ATxuvONcGpz@bogus
[2] https://lore.kernel.org/all/0411f99d-231a-af4b-d681-7f7748361aa3@quicinc.com