Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Florian Fainelli <f.fainelli@gmail.com>]

On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> 
> Currently, when SMC/HVC is used as transport, the base address of the
> shared memory used for communication is not passed to the SMCCC call.
> This means that such an address must be hard-coded into the bootloader.
> 
> In order to increase flexibility and allow the memory layout to be
> changed without modifying the bootloader, this patch adds the shared
> memory base address to the a1 argument of the SMCCC call.
> 
> On the Secure Monitor side, the service call implementation can
> therefore read the a1 argument in order to know the location of the
> shared memory to use. This change is backward compatible to existing
> service call implementations as long as they don't check for a1 to be
> zero.

resource_size_t being defined after phys_addr_t, its size is different
between 32-bit, 32-bit with PAE and 64-bit so it would probably make
more sense to define an physical address alignment, or maybe an address
that is in multiple of 4KBytes so you can address up to 36-bits of
physical address even on a 32-bit only system?

What discovery mechanism does the OS have that the specified address
within the SMCCC call has been accepted by the firmware given the return
value of that SMCCC call does not appear to be used or checked? Do we
just expect a timeout initializing the SCMI subsystem?

Given that the kernel must somehow reserve this memory as a shared
memory area for obvious reasons, and the trusted firmware must also
ensure it treats this memory region with specific permissions in its
translation regime, does it really make sense to give that much flexibility?

If your boot loader has FDT patching capability, maybe it can also do a
SMC call to provide the address to your trusted firmware, prior to
loading the Linux kernel, and then they both agree, prior to boot about
the shared memory address?

> 
> Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> Signed-off-by: Paul J. Murphy <paul.j.murphy@intel.com>
> ---
>  drivers/firmware/arm_scmi/smc.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
> index 49bc4b0e8428..aef3a58f8266 100644
> --- a/drivers/firmware/arm_scmi/smc.c
> +++ b/drivers/firmware/arm_scmi/smc.c
> @@ -21,12 +21,14 @@
>   *
>   * @cinfo: SCMI channel info
>   * @shmem: Transmit/Receive shared memory area
> + * @shmem_paddr: Physical address of shmem
>   * @func_id: smc/hvc call function id
>   */
>  
>  struct scmi_smc {
>  	struct scmi_chan_info *cinfo;
>  	struct scmi_shared_mem __iomem *shmem;
> +	resource_size_t shmem_paddr;
>  	struct mutex shmem_lock;
>  	u32 func_id;
>  };
> @@ -73,6 +75,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
>  		dev_err(dev, "failed to ioremap SCMI Tx shared memory\n");
>  		return -EADDRNOTAVAIL;
>  	}
> +	scmi_info->shmem_paddr = res.start;
>  
>  	ret = of_property_read_u32(dev->of_node, "arm,smc-id", &func_id);
>  	if (ret < 0)
> @@ -109,7 +112,8 @@ static int smc_send_message(struct scmi_chan_info *cinfo,
>  
>  	shmem_tx_prepare(scmi_info->shmem, xfer);
>  
> -	arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res);
> +	arm_smccc_1_1_invoke(scmi_info->func_id, scmi_info->shmem_paddr, 0, 0,
> +			     0, 0, 0, 0, &res);
>  	scmi_rx_callback(scmi_info->cinfo, shmem_read_header(scmi_info->shmem));
>  
>  	mutex_unlock(&scmi_info->shmem_lock);
> 

-- 
Florian