Re: [PATCH] firmware: arm_scmi: Give SMC transport precedence over mailbox

[Florian Fainelli]

On 10/7/24 06:13, Sudeep Holla wrote:
> On Sat, Oct 05, 2024 at 09:33:17PM -0700, Florian Fainelli wrote:
> > Broadcom STB platforms have for historical reasons included both
> > "arm,scmi-smc" and "arm,scmi" in their SCMI Device Tree node compatible
> > string.
>
> I assume in the same order.

That is correct, in that exact order indeed.

> > After the commit cited in the Fixes tag and with a kernel
> > configuration that enables both the SCMI and the Mailbox transports, we
>
> ^^^^^ s/SCMI/SMC ?

Yes, this should read "SMC" here.

> > would probe the mailbox transport, but fail to complete since we would
> > not have a mailbox driver available.
>
> I always assumed the node compatible match happens from the more specific
> compatible(on the left) to the more generic ones(on the right) from the
> compatible property list. Looks like that was a wrong assumption then ?

This is the correct assumption, and this worked very well, and we were 
utilizing that as long as all of the transports where "sub" entities 
within the common and single arm_scmi platform device.

When breaking up the transports into individual platform drivers, now 
each one is responsible for matching, and if they are all built-into the 
kernel, they are matching in the order in which they have been linked 
into the kernel.

> > By keeping the SMC transport objects linked first, we can let the
> > platform driver, match the compatible string and probe successfully with
> > no adverse effects on platforms using the mailbox transport.
>
> I don't have strong objection to the patch itself, happy to get it merged.
> Just curious if my understanding of the issue is correct. I think Cristian
> has more detailed query, so just responding to that will suffice.

Sounds good, thanks.

> > Fixes: b53515fa177c ("firmware: arm_scmi: Make MBOX transport a standalone driver")
> > Signed-off-by: Florian Fainelli <florian.fainelli@xxxxxxxxxxxx>
> > Change-Id: I8e348e3e0deabdc5c1d596929d7f9134793f346e
>
> Spurious from internal gerrit repo ?

Indeed, will post v2 with the typo you highlighted and that remove, and 
any additional explanation Cristian deems necessary to add, thanks!
--
Florian