On Wed, Feb 26, 2025 at 05:19:53PM +0000, Sudeep Holla wrote:

On Wed, Feb 26, 2025 at 10:09:45AM -0600, Rob Herring wrote:

quoted

On Wed, Feb 26, 2025 at 05:44:56PM +0800, Peng Fan (OSS) wrote:

quoted

Quote Sudeep's reply"
I am not blocking you. What I mentioned is I don't agree that DT can be used
to resolve this issue, but I don't have time or alternate solution ATM. So
if you propose DT based solution and the maintainers agree for the proposed
bindings I will take a look and help you to make that work. But I will raise
any objections I may have if the proposal has issues mainly around the
compatibility and ease of maintenance.
"

This all looks to me like SCMI has failed to provide common interfaces.

We can look into this if having such common interface can solve this problem.

quoted

I'm indifferent. If everyone involved thinks adding compatibles will
solve whatever the issues are, then it's going to be fine with me
(other than the issue above). It doesn't seem like you have that, so I
don't know that I'd keep going down this path.

Sorry if I was ambiguous with my stance as quoted above. For me, 2 devices
pointing to the same node seems implementation issue rather than fixing/
working around by extending DT bindings like this $subject patch is
attempting.

If you disagree with that and think 2 devices in the kernel shouldn't
point to the same device tree node, then yes I see this is right approach
to take. ATM I don't know which is correct and what are other developer's
include DT maintainer opinion on this. I just didn't like the way Peng
was trying to solve it with some block/allow list which wouldn't have
fixed the issue or just created new ones.

With compatible string, no need block/allow list anymore I think.

But honestly I have not spend efforts on do driver changes to support
compatible string. If in the end we all agree on the proposal,
I could start on driver changes.

Thanks,
Peng

--
Regards,
Sudeep