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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CA+-6iNzS6oL5MKKbxRPi_xjK7F+=1T03RO3_A4skUZ3xJHOC0A@mail.gmail.com>
Date:   Wed, 21 Oct 2020 17:38:12 -0400
From:   Jim Quinlan <james.quinlan@...adcom.com>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" 
        <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 Fri, Oct 9, 2020 at 12:38 PM Sudeep Holla <sudeep.holla@....com> 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.

Hi Sudeep,

Sorry for the delay.  As Florian mentioned, we tried to use what
you've submitted but could not because in our system a return does not
indicate the completion of the SCMI operation.  It is indicated by an
interrupt.  There are a number of reasons for this and some are out of
our control.
>
>
> > 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.

Yes, we are using fast SMC calls.  We don't have multiple message
support either.  The disconnect we have with the smc/hvc transport
commit si this:

smc_send_message(...)
{
/* ... */
+ arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res);
+ scmi_rx_callback(scmi_info->cinfo, shmem_read_header(scmi_info->shmem));

In our code the second line is not here but in the interrupt handler.
I don't see any way you can easily change/augment the smc/hvc
transport to accommodate us.

Regards,
Jim





>
>
> --
> Regards,
> Sudeep

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4167 bytes)