All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Rob Herring <robh@kernel.org>
Cc: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
	cristian.marussi@arm.com, Sudeep Holla <sudeep.holla@arm.com>,
	saravanak@google.com, krzk+dt@kernel.org, conor+dt@kernel.org,
	arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Peng Fan <peng.fan@nxp.com>
Subject: Re: [RFC] dt-bindings: firmware: scmi: Introduce compatible string
Date: Wed, 26 Feb 2025 17:19:53 +0000	[thread overview]
Message-ID: <Z79NOeyWzfRio8qs@bogus> (raw)
In-Reply-To: <20250226160945.GA2505223-robh@kernel.org>

On Wed, Feb 26, 2025 at 10:09:45AM -0600, Rob Herring wrote:
> On Wed, Feb 26, 2025 at 05:44:56PM +0800, Peng Fan (OSS) wrote:
> > 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.

> 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.

--
Regards,
Sudeep

  reply	other threads:[~2025-02-26 17:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-26  9:44 [RFC] dt-bindings: firmware: scmi: Introduce compatible string Peng Fan (OSS)
2025-02-26 16:09 ` Rob Herring
2025-02-26 17:19   ` Sudeep Holla [this message]
2025-02-27  3:15     ` Peng Fan
2025-02-27  9:12       ` Sudeep Holla
2025-02-27  3:09   ` Peng Fan
2025-02-28 13:34     ` Rob Herring
2025-02-28 14:04       ` Sudeep Holla
2025-02-28 14:17         ` Rob Herring
2025-03-03  4:35           ` Peng Fan
2025-02-27 11:48 ` Cristian Marussi
2025-03-03  4:27   ` Peng Fan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z79NOeyWzfRio8qs@bogus \
    --to=sudeep.holla@arm.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=cristian.marussi@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peng.fan@nxp.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=robh@kernel.org \
    --cc=saravanak@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.