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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <17593cd5-e188-4146-8e4b-c87ce48e1140@broadcom.com>
Date: Mon, 7 Oct 2024 09:47:06 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: linux-arm-kernel@...ts.infread.org, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Cristian Marussi <cristian.marussi@....com>,
 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
 <devicetree@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>,
 "open list:SYSTEM CONTROL & POWER/MANAGEMENT INTERFACE"
 <arm-scmi@...r.kernel.org>,
 "moderated list:SYSTEM CONTROL & POWER/MANAGEMENT INTERFACE"
 <linux-arm-kernel@...ts.infradead.org>, justin.chen@...adcom.com,
 opendmb@...il.com, kapil.hali@...adcom.com,
 bcm-kernel-feedback-list@...adcom.com, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH] firmware: arm_scmi: Give SMC transport precedence over
 mailbox

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@...adcom.com>
>> 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