Re: [PATCH v4 03/37] firmware: arm_scmi: introduce devres get/put protocols operations

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

Re: [PATCH v2 2/8] firmware: arm_scmi: introduce protocol handles

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

Re: [PATCH v3 1/4] firmware: arm_scmi: Add Voltage Domain Support

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). > > &

Re: [PATCH v3 1/4] firmware: arm_scmi: Add Voltage Domain Support

ruct 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/arm_sc

Re: [PATCH v2 3/4] regulator: add SCMI driver

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

Re: [PATCH v2 1/4] firmware: arm_scmi: Add Voltage Domain Support

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 +- >

Re: [PATCH] firmware: arm_scmi: Add missing Rx size re-initialisation

y 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 protocol") &

Re: [PATCH 3/5] firmware: arm_scmi: add config dependency for smc transport

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

Re: [PATCH 4/5] firmware: arm_scmi: smc transport supports multi-message pool

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: > > > > > >

Re: [PATCH 4/5] firmware: arm_scmi: smc transport supports multi-message pool

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

Re: [PATCH 2/5] firmware: arm_scmi: fix transfer missing re-initialization

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() > >

Re: [PATCH 3/5] firmware: arm_scmi: add config dependency for smc transport

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 t

Re: [PATCH 1/5] firmware: arm_scmi: always initialize protocols

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

[PATCH 4/5] firmware: arm_scmi: smc transport supports multi-message pool

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

[PATCH 1/5] firmware: arm_scmi: always initialize protocols

. 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

[PATCH 2/5] firmware: arm_scmi: fix transfer missing re-initialization

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

[PATCH 3/5] firmware: arm_scmi: add config dependency for smc transport

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 @@

[PATCH 5/5] firmware: arm_scmi: fix ARCH_COLD_RESET

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

Re: [PATCH 1/4] firmware: arm_scmi: Add Voltage Domain Support

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 |

Re: [PATCH] firmware: arm_scmi: fix SMCCC_RET_NOT_SUPPORTED management

> > 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 >

RE: [PATCH v3 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support

-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]: Tested-by:

Re: [PATCH] firmware: arm_scmi: fix SMCCC_RET_NOT_SUPPORTED management

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 unsupport

Re: [PATCH 2/2] firmware: psci: support SMCCC v1.2 for SMCCC conduit

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.

Re: [PATCH 1/2] firmware: arm-smccc: define identifier for Arm SMCCC v1.2

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

[PATCH] firmware: arm_scmi: fix SMCCC_RET_NOT_SUPPORTED management

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

[PATCH 1/2] firmware: arm-smccc: define identifier for Arm SMCCC v1.2

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

[PATCH 2/2] firmware: psci: support SMCCC v1.2 for SMCCC conduit

=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

[PATCH v2] dt-bindings: nvmem: stm32: new property for data access

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

Re: [PATCH] dt-bindings: nvmem: stm32: new property for data access

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

[PATCH] dt-bindings: nvmem: stm32: new property for data access

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

[PATCH] ARM: dts: stm32: bump PSCI to version 1.0 on stm32mp15x

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

Re: [PATCH 2/5] firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol

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

Re: [PATCH v2 6/6] firmware: arm_scmi: Check if platform has released shmem before using

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

[PATCH] tee: check shm references are consistent in offset/size

due to the memory allocation granule. Reported-by: Alexandre Jutras <alexandre.jut...@nxp.com> Signed-off-by: Etienne Carriere <etienne.carri...@linaro.org> --- drivers/tee/tee_core.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/tee/tee_core.c b/drivers/te

[PATCH] tee: check shm references are consistent in offset/size

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

[PATCH] tee: check shm references are consistent in offset/size

<alexandre.jut...@nxp.com> Signed-off-by: Etienne Carriere <etienne.carri...@linaro.org> --- 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_

[PATCH] tee: check shm references are consistent in offset/size

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

Re: [PATCH] arm: l2c: unlock ways when in non-secure mode

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

Re: [PATCH] arm: l2c: unlock ways when in non-secure mode

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