On Tue, Mar 12, 2024 at 09:52:56AM -0700, Nikunj Kela wrote: > +Trilok > > On 3/4/2024 3:01 AM, Sudeep Holla wrote: > > arch/arm64/boot/dts/arm/juno-scmi.dts > > > > One is with old firmware interface and -scmi is with SCMI. No new top > > level compatible change is needed. I understand it was switch from one > > interface to the another and not like Qcom platforms which is moving > > from in-kernel solution to firmware solution. But the general rule applies > > here as well unless there are specific reasons for needing that exception. > > I am not against it or ruling that out, just curious to understand them. > > Thank you all for all your inputs on this. I discussed this with Srini and > he suggested that we could use a new optional DT property like "qcom, > fw-managed" to ascertain if we are running on firmware managed variant. Thus > each device node in the dts can add this. I did ask him if, instead of > putting it to each device node, we can use it at the board level however he > thinks that it would not be easy to update yaml documentation on DT nodes > with board level property. So if everyone here agrees with this approach, I > would like to close this thread. The counter argument from me for that is simple. If you are OK to manage with one board level compatible/property(doesn't matter for this discussion), then why can't that be the compatible of the firmware itself(SCMI and RPMI both must have their own compatible already). The main point is why do you need any extra information when they are already present. My comment is just for this one board level compatible/property. -- Regards, Sudeep
