On Fri, 8 Jan 2021 at 13:24, Cristian Marussi wrote:
>
> On Thu, Jan 07, 2021 at 09:28:37AM -0500, Thara Gopinath wrote:
> >
> >
> > On 1/6/21 3:15 PM, Cristian Marussi wrote:
> > > Expose to the SCMI drivers a new devres managed common protocols API based
> > > on generic get/put methods and prot
Hello Thara,
On Wed, 4 Nov 2020 at 17:16, Thara Gopinath wrote:
>
>
> Hi Cristian,
>
> On 10/28/20 4:29 PM, Cristian Marussi wrote:
> > Add basic protocol handles definitions and helpers support.
> > All protocols initialization code and SCMI drivers probing is still
> > performed using the handl
On Wed, 28 Oct 2020 at 21:44, Cristian Marussi wrote:
>
> On Wed, Oct 28, 2020 at 03:29:57PM +0100, Etienne Carriere wrote:
> > Hi Cristian,
> >
> > Some remaining minor comments see below.
> > FYI I've successfully tested this series (the 4 patches).
> &
om struct voltage_info
>
> v1 --> v2
> - fix voltage levels query loop to reload full cmd description
> between iterations as reported by Etienne Carriere
> - ensure rx buffer is properly sized calli scmi_reset_rx_to_maxsz
> between transfers
> ---
> drivers/firmware/a
Hi Cristian,
Some minor comments...
Etienne
On Thu, 15 Oct 2020 at 17:40, Cristian Marussi wrote:
>
> Add a simple regulator based on SCMI Voltage Domain Protocol.
>
> Signed-off-by: Cristian Marussi
>
> v1 --> v2
> - removed duplicate regulator naming
> - removed redundant .get/set_volt
t; v2
> - fix voltage levels query loop to reload full cmd description
> between iterations as reported by Etienne Carriere
> - ensure rx buffer is properly sized calli scmi_reset_rx_to_maxsz
> between transfers
> ---
> drivers/firmware/arm_scmi/Makefile | 2 +-
>
size set by previous
> response.
>
> Let us reset the receive buffer size to max possible in such cases as
> we don't know the exact size of the response.
>
> Fixes: b6f20ff8bd94 ("firmware: arm_scmi: add common infrastructure and
> support for base pr
On Fri, 9 Oct 2020 at 17:58, Sudeep Holla wrote:
>
> On Fri, Oct 09, 2020 at 02:33:41PM +0200, Etienne Carriere wrote:
> > On Thu, 8 Oct 2020 at 23:08, Sudeep Holla wrote:
> > >
> > > On Thu, Oct 08, 2020 at 04:37:20PM +0200, Etienne Carriere wrote:
> > &g
On Mon, 12 Oct 2020 at 10:57, Sudeep Holla wrote:
>
> On Fri, Oct 09, 2020 at 04:17:52PM +0100, Sudeep Holla wrote:
> > On Fri, Oct 09, 2020 at 02:43:31PM +0200, Etienne Carriere wrote:
> > > On Thu, 8 Oct 2020 at 23:11, Sudeep Holla wrote:
> > > >
> >
On Thu, 8 Oct 2020 at 23:11, Sudeep Holla wrote:
>
> On Thu, Oct 08, 2020 at 04:37:21PM +0200, Etienne Carriere wrote:
> > There is no reason for the smc transport to restrict itself to a 1
> > message pool. More can be allocated, messages are copied from/to the
> > shared
On Thu, 8 Oct 2020 at 23:18, Sudeep Holla wrote:
>
> On Thu, Oct 08, 2020 at 04:37:19PM +0200, Etienne Carriere wrote:
> > Implement helper function scmi_do_xfer_again() to process consecutive
> > transfers that are initialized only once with scmi_xfer_get_init()
> >
On Thu, 8 Oct 2020 at 23:08, Sudeep Holla wrote:
>
> On Thu, Oct 08, 2020 at 04:37:20PM +0200, Etienne Carriere wrote:
> > Fix dependencies for configuration switch ARM_SCMI_PROTOCOL that
> > is not exclusively dependent on MAILBOX since the alternate
> > smc tran
On Thu, 8 Oct 2020 at 21:17, Sudeep Holla wrote:
>
> On Thu, Oct 08, 2020 at 04:37:18PM +0200, Etienne Carriere wrote:
> > Remove the IDR replacement that prevent initializing an SCMI protocol
> > when it has already been initialized. This is needed when there are
> > sev
could fit. This should be something configurable.
Signed-off-by: Etienne Carriere
Cc: Peng Fan
---
drivers/firmware/arm_scmi/smc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
index 1a03c3ec0230
.
Signed-off-by: Etienne Carriere
---
drivers/firmware/arm_scmi/bus.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index 1377ec76a45d..8ea04b069129 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware
Implement helper function scmi_do_xfer_again() to process consecutive
transfers that are initialized only once with scmi_xfer_get_init()
and hence get the pool completion and responses message length not
reloaded regarding last completed transfer.
Signed-off-by: Etienne Carriere
---
drivers
CI_FW")
Signed-off-by: Etienne Carriere
---
drivers/firmware/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 3315e3c21586..5bdd411206ff 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@
Fix ARCH_COLD_RESET according to SCMI specification.
Signed-off-by: Etienne Carriere
---
drivers/firmware/arm_scmi/reset.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/firmware/arm_scmi/reset.c
b/drivers/firmware/arm_scmi/reset.c
index f063cfe17e02
Hello Christian,
I faced an issue with this change, see below.
On Tue, 6 Oct 2020 at 00:26, Cristian Marussi wrote:
>
> Add SCMI Voltage Domain protocol support.
>
> Signed-off-by: Cristian Marussi
> ---
> drivers/firmware/arm_scmi/Makefile | 2 +-
> drivers/firmware/arm_scmi/common.h |
> > Or consider part of the SCMI-SMC transport API that output arg a0
> > shall be 0 on success, SMCCC_RET_NOT_SUPPORTED if function ID is not
> > supported and any non-zero value for non-generic **error** codes.
> >
>
> I prefer that. Anyways I will check and if anything changes I will ping
> back
ed both TF-A (v2.x) and
OP-TEE (3.7.0, 3.9.0-rc) as runtime secure firmware.
Helper functions arm_smccc_1_1_get_conduit()/arm_smccc_1_1_invoke()
works as expected AFAICT. No regression seen with older secure
firmwares.
For the patches 1 to 6, as I poorly tested [v3,7/7] soc ids,
based on tag next-20200505 [1]:
On Thu, 14 May 2020 at 16:29, Sudeep Holla wrote:
>
> On Thu, May 14, 2020 at 10:24:28AM +0200, Etienne Carriere wrote:
> > Fix management of argument a0 output value of arm_smccc_1_1_invoke() that
> > should consider only SMCCC_RET_NOT_SUPPORTED as reporting an unsupported
On Thu, 14 May 2020 at 16:24, Sudeep Holla wrote:
>
> On Thu, May 14, 2020 at 10:21:09AM +0200, Etienne Carriere wrote:
> > Update PSCI driver to support SMCCC v1.2 reported by secure firmware
> > and indirectly make SMCCC conduit properly set when so. TF-A release
> > v2.
On Thu, 14 May 2020 at 14:38, Steven Price wrote:
>
> On 14/05/2020 09:21, Etienne Carriere wrote:
> > Define identifier value reported by secure firmware when its
> > supports Arm SMCCC specification v1.2.
> >
> > Signed-off-by: Etienne Carriere
>
> FYI Sud
Fix management of argument a0 output value of arm_smccc_1_1_invoke() that
should consider only SMCCC_RET_NOT_SUPPORTED as reporting an unsupported
function ID as correctly stated in the inline comment.
Signed-off-by: Etienne Carriere
---
drivers/firmware/arm_scmi/smc.c | 2 +-
1 file changed, 1
Define identifier value reported by secure firmware when its
supports Arm SMCCC specification v1.2.
Signed-off-by: Etienne Carriere
---
include/linux/arm-smccc.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 59494df0f55b
=e34cc0cedca6e229847c232fe58d37fad2610ce9
Signed-off-by: Etienne Carriere
---
drivers/firmware/psci/psci.c | 14 ++
include/linux/psci.h | 1 +
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 2937d44b5df4
From: Etienne Carriere
Introduce boolean property st,non-secure-otp for OTP data located
in a factory programmed area that only secure firmware can access
by default and that shall be reachable from the non-secure world.
This change also allows additional properties for NVMEM nodes that
were
Hello Rob,
On Tue, 12 May 2020 at 03:51, Rob Herring wrote:
>
> On Fri, May 8, 2020 at 8:47 AM Etienne Carriere
> wrote:
> >
> > From: Etienne Carriere
> >
> > Introduce boolean property st,non-secure-otp for OTP data located
> > in a factory progra
From: Etienne Carriere
Introduce boolean property st,non-secure-otp for OTP data located
in a factory programmed area that only secure firmware can access
by default and that shall be reachable from the non-secure world.
Signed-off-by: Etienne Carriere
---
.../bindings/nvmem/st,stm32
From: Etienne Carriere
Declare PSCI v1.0 support instead of v0.1 as the former is supported
by the PSCI firmware stacks stm32mp15x relies on.
Signed-off-by: Etienne Carriere
---
arch/arm/boot/dts/stm32mp151.dtsi | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm
On Fri, 26 Jul 2019 at 16:00, Sudeep Holla wrote:
>
> SCMI v2.0 adds support for "FastChannel" which do not use a message
> header as they are specialized for a single message.
>
> Only PERFORMANCE_LIMITS_{SET,GET} and PERFORMANCE_LEVEL_{SET,GET}
> commands are supported over fastchannels. As they
Hello Sudeep,
On Fri, 26 Jul 2019 at 15:46, Sudeep Holla wrote:
>
> Sometimes platfom may take too long to respond to the command and OS
> might timeout before platform transfer the ownership of the shared
> memory region to the OS with the response.
>
> Since the mailbox channel associated with
due to the memory allocation granule.
Reported-by: Alexandre Jutras
Signed-off-by: Etienne Carriere
---
drivers/tee/tee_core.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
index 0124a91..dd46b75 100644
--- a/drivers/tee
Signed-off-by: Etienne Carriere
---
drivers/tee/tee_core.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
index 0124a91..dd46b75 100644
--- a/drivers/tee/tee_core.c
+++ b/drivers/tee/tee_core.c
@@ -238,6 +238,17 @@ static int
Hello,
On 3 December 2017 at 12:20, Peng Fan wrote:
> Hi Russell,
>
>> > > > > >
>> > > > > > On Sun, Nov 26, 2017 at 08:25:30PM +0800, Peng Fan wrote:
>> > > > > > > To boot Linux in Non-secure mode with l2x0, the l2x0
>> > > > > > > controller is enabled in secure mode and ways locked to make
>
36 matches
Mail list logo