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: <AM0PR04MB4481C44F9B5EFCDD076EF728881D0@AM0PR04MB4481.eurprd04.prod.outlook.com>
Date:   Mon, 27 May 2019 05:19:41 +0000
From:   Peng Fan <peng.fan@....com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "jassisinghbrar@...il.com" <jassisinghbrar@...il.com>,
        "sudeep.holla@....com" <sudeep.holla@....com>
CC:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "andre.przywara@....com" <andre.przywara@....com>,
        "van.freenix@...il.com" <van.freenix@...il.com>,
        "festevam@...il.com" <festevam@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox

Hi Florian,

> Subject: Re: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox
> 
> Hi,
> 
> On 5/22/19 10:50 PM, Peng Fan wrote:
> > This is a modified version from Andre Przywara's patch series
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Fpatchwork%2Fcover%2F812997%2F&amp;data=02%7C01%7Cpe
> ng.fan%40nxp.com%7C010c9ddd5df645c9c66b08d6dfa46cb2%7C686ea1d3b
> c2b4c6fa92cd99c5c301635%7C0%7C0%7C636942294631442665&amp;sdat
> a=BbS5ZQtzMANSwaKRDJ62NKrPrAyaED1%2BvymQaT6Qr8E%3D&amp;rese
> rved=0.
> > [1] is a draft implementation of i.MX8MM SCMI ATF implementation that
> > use smc as mailbox, power/clk is included, but only part of clk has
> > been implemented to work with hardware, power domain only supports get
> > name for now.
> >
> > The traditional Linux mailbox mechanism uses some kind of dedicated
> > hardware IP to signal a condition to some other processing unit,
> > typically a dedicated management processor.
> > This mailbox feature is used for instance by the SCMI protocol to
> > signal a request for some action to be taken by the management processor.
> > However some SoCs does not have a dedicated management core to
> provide
> > those services. In order to service TEE and to avoid linux shutdown
> > power and clock that used by TEE, need let firmware to handle power
> > and clock, the firmware here is ARM Trusted Firmware that could also
> > run SCMI service.
> >
> > The existing SCMI implementation uses a rather flexible shared memory
> > region to communicate commands and their parameters, it still requires
> > a mailbox to actually trigger the action.
> 
> We have had something similar done internally with a couple of minor
> differences:
> 
> - a SGI is used to send SCMI notifications/delayed replies to support
> asynchronism (patches are in the works to actually add that to the Linux SCMI
> framework). There is no good support for SGI in the kernel right now so we
> hacked up something from the existing SMP code and adding the ability to
> register our own IPI handlers (SHAME!). Using a PPI should work and should
> allow for using request_irq() AFAICT.

So you are also implementing a firmware inside ATF for SCMI usecase, right?

Introducing SGI in ATF to notify Linux will introduce complexity, there is
no good framework inside ATF for SCMI, and I use synchronization call for
simplicity for now.

> 
> - the mailbox identifier is indicated as part of the SMC call such that we can
> have multiple SCMI mailboxes serving both standard protocols and
> non-standard (in the 0x80 and above) range, also they may have different
> throughput (in hindsight, these could simply be different channels)
> 
> Your patch series looks both good and useful to me, I would just put a
> provision in the binding to support an optional interrupt such that
> asynchronism gets reasonably easy to plug in when it is available (and
> desirable).

Ok. Let me think about and add that in new version patch.

Thanks,
Peng.

> 
> >
> > This patch series provides a Linux mailbox compatible service which
> > uses smc calls to invoke firmware code, for instance taking care of SCMI
> requests.
> > The actual requests are still communicated using the standard SCMI way
> > of shared memory regions, but a dedicated mailbox hardware IP can be
> > replaced via this new driver.
> >
> > This simple driver uses the architected SMC calling convention to
> > trigger firmware services, also allows for using "HVC" calls to call
> > into hypervisors or firmware layers running in the EL2 exception level.
> >
> > Patch 1 contains the device tree binding documentation, patch 2
> > introduces the actual mailbox driver.
> >
> > Please note that this driver just provides a generic mailbox
> > mechanism, though this is synchronous and one-way only (triggered by
> > the OS only, without providing an asynchronous way of triggering
> > request from the firmware).
> > And while providing SCMI services was the reason for this exercise,
> > this driver is in no way bound to this use case, but can be used
> > generically where the OS wants to signal a mailbox condition to
> > firmware or a hypervisor.
> > Also the driver is in no way meant to replace any existing firmware
> > interface, but actually to complement existing interfaces.
> >
> > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >
> ub.com%2FMrVan%2Farm-trusted-firmware%2Ftree%2Fscmi&amp;data=02
> %7C01%7
> >
> Cpeng.fan%40nxp.com%7C010c9ddd5df645c9c66b08d6dfa46cb2%7C686ea1
> d3bc2b4
> >
> c6fa92cd99c5c301635%7C0%7C0%7C636942294631442665&amp;sdata=kN
> 9bEFFcsZA
> > 1ePeNLLfHmONpVaG6O5ajVQvKMuaBXyk%3D&amp;reserved=0
> >
> > Peng Fan (2):
> >   DT: mailbox: add binding doc for the ARM SMC mailbox
> >   mailbox: introduce ARM SMC based mailbox
> >
> >  .../devicetree/bindings/mailbox/arm-smc.txt        |  96
> +++++++++++++
> >  drivers/mailbox/Kconfig                            |   7 +
> >  drivers/mailbox/Makefile                           |   2 +
> >  drivers/mailbox/arm-smc-mailbox.c                  | 154
> +++++++++++++++++++++
> >  include/linux/mailbox/arm-smc-mailbox.h            |  10 ++
> >  5 files changed, 269 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/mailbox/arm-smc.txt
> >  create mode 100644 drivers/mailbox/arm-smc-mailbox.c  create mode
> > 100644 include/linux/mailbox/arm-smc-mailbox.h
> >
> 
> 
> --
> Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ