| 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
| ||
|
Message-ID: <AM0PR04MB44815CAA10EAB980B094679688840@AM0PR04MB4481.eurprd04.prod.outlook.com>
Date: Tue, 24 Sep 2019 09:39:56 +0000
From: Peng Fan <peng.fan@....com>
To: André Przywara <andre.przywara@....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>,
"f.fainelli@...il.com" <f.fainelli@...il.com>
CC: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
dl-linux-imx <linux-imx@....com>
Subject: RE: [PATCH V7 0/2] mailbox: arm: introduce smc triggered mailbox
Hi Andre,
> Subject: Re: [PATCH V7 0/2] mailbox: arm: introduce smc triggered mailbox
>
> On 23/09/2019 07:36, Peng Fan wrote:
>
> Hi Peng,
>
> thanks for the update!
>
> > From: Peng Fan <peng.fan@....com>
> >
> > V7:
> > Typo fix
> > #mbox-cells changed to 0
> > Add a new header file arm-smccc-mbox.h Use ARM_SMCCC_IS_64
> >
> > Andre,
> > The function_id is still kept in arm_smccc_mbox_cmd, because
> > arm,func-id property is optional, so clients could pass function_id to mbox
> driver.
>
> Well, to be honest, this is the main thing I am opposing:
>
> It should *not* be optional.
>
> The controller driver DT node should *always* contain the function ID.
> The reasons for that I explained in the other emails to Jassi:
> We can't safely execute smc calls from the Linux kernel, unless we also
> comply with the SMCCC standard. So we should not leave the choice of the
> function ID to the mailbox client.
> Also this much better separates the mailbox controller driver from the client.
>
> So I think we should reach an agreement here.
I am ok to mark it as a required property in v9, but I am not sure Jassi accept it.
Thanks,
Peng.
>
> Cheers,
> Andre
>
> > V6:
> > Switch to per-channel a mbox controller Drop arm,num-chans,
> > transports, method Add arm,hvc-mbox compatible Fix smc/hvc args, drop
> > client id and use correct type.
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fcover%2F11146641%2F&data=02%7C01%7Cpeng.f
> an%40n
> >
> xp.com%7C52d7e331c222426852a508d740ae7d42%7C686ea1d3bc2b4c6fa9
> 2cd99c5c
> >
> 301635%7C0%7C0%7C637048990507177346&sdata=N%2BWdEXh9QXn
> F4cn2DjCwHk
> > qpD1JxtP%2BBfQwn3E3lzYs%3D&reserved=0
> >
> > V5:
> > yaml fix
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fcover%2F11117741%2F&data=02%7C01%7Cpeng.f
> an%40n
> >
> xp.com%7C52d7e331c222426852a508d740ae7d42%7C686ea1d3bc2b4c6fa9
> 2cd99c5c
> >
> 301635%7C0%7C0%7C637048990507177346&sdata=XcRM%2FH4ZQAU
> QmT%2FDlGzq
> > 93LjlVhUYuvEmdYSezivTog%3D&reserved=0
> >
> > V4:
> > yaml fix for num-chans in patch 1/2.
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fcover%2F11116521%2F&data=02%7C01%7Cpeng.f
> an%40n
> >
> xp.com%7C52d7e331c222426852a508d740ae7d42%7C686ea1d3bc2b4c6fa9
> 2cd99c5c
> >
> 301635%7C0%7C0%7C637048990507177346&sdata=8f0Etfnd29Q6LHx
> bymLVyvEE
> > 7ElGZzN3uVMcIL%2BmZNQ%3D&reserved=0
> >
> > V3:
> > Drop interrupt
> > Introduce transports for mem/reg usage Add chan-id for mem usage
> > Convert to yaml format
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fcover%2F11043541%2F&data=02%7C01%7Cpeng.f
> an%40n
> >
> xp.com%7C52d7e331c222426852a508d740ae7d42%7C686ea1d3bc2b4c6fa9
> 2cd99c5c
> >
> 301635%7C0%7C0%7C637048990507177346&sdata=U2%2BjaU06Iu0h
> ULuCz0RT1r
> > vhSfjsu%2BWuKzjTfY7MuNw%3D&reserved=0
> >
> > V2:
> > 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&data=02%7C01%7Cpe
> ng.fan%40nxp.com%7C52d7e331c222426852a508d740ae7d42%7C686ea1d3
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637048990507177346&sda
> ta=dku%2BfT%2BDLilVU5T0fdHMzuUi4DYCM7aV1FQB4vaKCVE%3D&re
> served=0.
> > The modification are mostly:
> > Introduce arm,num-chans
> > Introduce arm_smccc_mbox_cmd
> > txdone_poll and txdone_irq are both set to false arm,func-ids are
> > kept, but as an optional property.
> > Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI.
> > Introduce interrupts notification.
> >
> > [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.
> >
> > 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, It could support synchronous TX/RX, or synchronous TX with
> > asynchronous RX. 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&data=02
> %7C01%7
> >
> Cpeng.fan%40nxp.com%7C52d7e331c222426852a508d740ae7d42%7C686ea
> 1d3bc2b4
> >
> c6fa92cd99c5c301635%7C0%7C0%7C637048990507177346&sdata=fFE
> KK8jYap5
> > igpH6ESGTHYfnhBZMsL2zB%2BdykMdOPwg%3D&reserved=0
> >
> >
> >
> > Peng Fan (2):
> > dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
> > mailbox: introduce ARM SMC based mailbox
> >
> > .../devicetree/bindings/mailbox/arm-smc.yaml | 95
> ++++++++++++
> > drivers/mailbox/Kconfig | 7 +
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 168
> +++++++++++++++++++++
> > 4 files changed, 272 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> >
Powered by blists - more mailing lists