linux-kernel - Re: [PATCH v3 2/2] mailbox: Add Broadcom STB mailbox driver

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 for Android: free password hash cracker in your pocket

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

Message-ID: <b4f88367-ff8b-08cb-16b3-7432aa6b3117@gmail.com>
Date:   Fri, 9 Oct 2020 10:03:27 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Sudeep Holla <sudeep.holla@....com>,
        Jim Quinlan <james.quinlan@...adcom.com>
Cc:     bcm-kernel-feedback-list@...adcom.com,
        Jassi Brar <jassisinghbrar@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        open list <linux-kernel@...r.kernel.org>,
        "moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 2/2] mailbox: Add Broadcom STB mailbox driver



On 10/9/2020 9:38 AM, Sudeep Holla wrote:
> On Sat, Sep 19, 2020 at 03:22:30PM -0400, Jim Quinlan wrote:
>> only implements the agent-to-platform channel;
> 
> In that case any reason why you can't reuse the existing smc transport
> for SCMI. It was added recently in case you haven't checked the latest
> kernel version(v5.8 or above). Check out for drivers/firmware/arm_scmi/smc.c
> IIUC rather vaguely Florian was cc-ed on those patches.

Our firmware completes all commands by posting an interrupt and we 
already have platforms in the field with this mailbox driver. I was 
hoping we could make use of the SMC transport, but the current firmware 
implementation completes commands by raising an interrupt. The reason 
why we did that was that we could support synchronous and asynchronous 
calls the same way.

> 
>> we may implement the platform-to-agent channel in the future.
> 
> This is not yet support with that transport, it is hard to generalise
> as different vendors have their own solutions there.
> 
>> An unusual aspect of this driver is how the completion of an SCMI message
>> is indicated.  An SCMI message is initiated with an ARM SMC call, but the
>> return of this call does not indicate the execution or completion of the
>> message.  Rather, the message's completion is signaled by an interrupt.
>>
> 
> So are these not fast SMC/HVC calls then ? If so we may need some changes
> to that driver. I just rejected multiple message support as we had assumed
> fast smc/hvc.
> 

-- 
Florian