public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Marek Vasut <marek.vasut@mailbox.org>
Cc: Marek Vasut <marek.vasut+renesas@mailbox.org>,
	arm-scmi@vger.kernel.org, Conor Dooley <conor+dt@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Cristian Marussi <cristian.marussi@arm.com>,
	Florian Fainelli <florian.fainelli@broadcom.com>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Rob Herring <robh@kernel.org>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property
Date: Thu, 23 Oct 2025 15:36:40 +0100	[thread overview]
Message-ID: <20251023-illustrious-almond-catfish-5010eb@sudeepholla> (raw)
In-Reply-To: <066449c8-4bca-41f1-990e-53d7672e3c0a@mailbox.org>

On Thu, Oct 23, 2025 at 03:42:02PM +0200, Marek Vasut wrote:
> On 10/23/25 3:16 PM, Sudeep Holla wrote:
> 
> Hello Sudeep,
> 
> > > +  arm,poll-transport:
> > > +    type: boolean
> > > +    description:
> > > +      An optional property which unconditionally forces polling in all transports.
> > > +      This is mainly mean to work around uncooperative SCP, which does not generate
> > > +      completion interrupts.
> > > +
> > 
> > Could you please clarify which platform and transport this change pertains to?
> 
> Renesas X5H with older SCP firmware , accessible via mailbox.
> 

So mailbox transport it is. Thanks for the info.

> > Introducing a property that enforces unconditional polling across all
> > platforms is not ideal - particularly if this is intended as a workaround
> > for a platform- or firmware- specific issue. Such implementations often get
> > replicated across platforms without addressing the root cause, leading to
> > wider inconsistencies.
> 
> The root cause is being addressed already, this is meant to keep the older
> SCP version operable.
> 

Good to know.

> > It would be preferable to scope this behavior using the platform’s compatible
> > string. This approach ensures the workaround is applied only to the affected
> > platform and prevents it from being inadvertently enabled elsewhere, unless
> > another platform intentionally uses the same compatible string (which seems
> > unlikely).
> 
> This is not platform-specific issue. SCMI provider which fails to generate
> interrupts can appear on any platform, using either transport, that is why I
> made the property generic.
> 

Good point, but ideally this is property of the transport itself. For example,
what does this "arm,poll-transport" can possibly mean for SMC/Optee transport ?

I understand this is a valid request, just not sure if this is the right way
to solve( i.e. Adding this property in the SCMI node in the proposed form).

Let me think and give others a chance to express their opinion.

-- 
Regards,
Sudeep

  parent reply	other threads:[~2025-10-23 14:36 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-23 12:35 [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property Marek Vasut
2025-10-23 12:35 ` [PATCH 2/2] firmware: arm_scmi: Implement " Marek Vasut
2025-10-23 13:07 ` [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document " Geert Uytterhoeven
2025-10-23 13:19   ` Marek Vasut
2025-10-23 13:16 ` Sudeep Holla
2025-10-23 13:42   ` Marek Vasut
2025-10-23 14:30     ` Cristian Marussi
2025-10-23 14:36       ` Marek Vasut
2025-10-23 14:36     ` Sudeep Holla [this message]
2025-10-23 14:47       ` Marek Vasut
2025-10-23 13:42   ` Sudeep Holla
2025-10-23 13:57     ` Marek Vasut
2025-10-23 13:45 ` Cristian Marussi
2025-10-23 14:00   ` Marek Vasut
2025-10-30  0:52     ` Marek Vasut
2025-11-13 11:03       ` Cristian Marussi
2025-11-13 11:34         ` Marek Vasut
2025-11-14  7:21         ` Wolfram Sang
2025-12-02 14:52         ` Sudeep Holla
2025-12-02 16:36           ` Marek Vasut
2025-12-02 18:55             ` Sudeep Holla
2025-12-02 19:25               ` Marek Vasut
2025-12-03 11:41                 ` Sudeep Holla
2025-12-03 22:53                   ` Marek Vasut
2025-12-04 12:33                     ` Sudeep Holla
2025-12-04 18:59                       ` Marek Vasut
2025-12-05  9:54                         ` Sudeep Holla
2025-12-07  9:16                           ` Marek Vasut
2025-12-08 16:30                             ` Sudeep Holla
2025-12-31 21:00                               ` Marek Vasut

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=20251023-illustrious-almond-catfish-5010eb@sudeepholla \
    --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=florian.fainelli@broadcom.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=marek.vasut@mailbox.org \
    --cc=robh@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox