From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.5 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13720C433E3 for ; Wed, 15 Jul 2020 22:45:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B93B120658 for ; Wed, 15 Jul 2020 22:45:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="tox4AkNh"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qKj4IWU5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B93B120658 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6pV5WuYn6oxeTjnPe/qxqyIqcQKAOpQMOmjEUmEPiKQ=; b=tox4AkNhYKBJfHthGFLbubhUx 6l0iICWLvW79G2Y8lo2QhSRAc9u8fueoEKz2hgVhpoUiZulHkYhxhBJOqOIeuU8hL59Dw4nbtlI1n 9oBNsSOV1C3OK5Dj+j5jW4ROjNhQwNsRkkNHCkoVVxGapalh4lNF9maIHfcexjrncN3qPoWlmOAFz huZ287TJeIPZ6ITGT2GoFSqsBNAOkhowicCrDiEeru1zH/0tc5yU93mZREPYfR5tnjwDWh6RROsSg v5eGhoR7236DP0fn+4RU0mOs9xdzA85xtosqNhr9b1F5BgNJTiZcS5B2vB823PX0VrtV1zlAVyZP4 D9E5L+kMQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvq7h-0003ZI-Gt; Wed, 15 Jul 2020 22:43:33 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvq7e-0003Yj-VU for linux-arm-kernel@lists.infradead.org; Wed, 15 Jul 2020 22:43:31 +0000 Received: by mail-wm1-x344.google.com with SMTP id 22so7552046wmg.1 for ; Wed, 15 Jul 2020 15:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=i9o/384l66MTrvWFtV9uTq7Mo/n8FiMV36XiAVH9gm8=; b=qKj4IWU5oCVZwjwjqLgQVeucO94cdzzmmFUrrkFHIHmtdIAp8oxJOekjS3mlJxtc0y o5+0vcoOW4oVbxFh6zclHCK3QRS+fcQkyjQn4dVCS8syJbNTJKC41bPaKtOgo/sv/njt TWUtGTzQ+UU/rARjI/b4TM0fmohLsJbMfzZaNSqK5c5EhMEcEWaIk7dZdA8JECtvqFSK zsEcbQMe9dUTM3UvbyI1nQN2nlh0Dz9qscEeCkIKB5Id/tVz6tIFXz8ZWKz8fyF9cDX1 FPUz5+HFHqllJ0uZl/5E0Sp7aY1L8BZfk8HHXtvZ5Pa8GRgP94B7v5peKZSkdWOOZzvd 53HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=i9o/384l66MTrvWFtV9uTq7Mo/n8FiMV36XiAVH9gm8=; b=UYDaG5Dp6eARVFvE62XeGQb9AEEmZU8HzADw2wUiwTTth+KCvjoHO8ToLjT4OQGFEG tojGVb8r9kxk7X6K9cXgblVwVy0+ItgNI3w0MF/QSG1wPxQBpO92JL04sTSZ2xBBhnSc HRQIy7oUktIgoSleeRhc2MP4nv/OrPsBqLmPC98PVelrE4SkFKpW0h5Chj07kWmbuUnO rVxlfBRFwcDkHB5JK6S1cd/srFRo0Zn395PqisVLClOMWP+Q4rhDkKmqqKTnAWGmyDH8 mCg5jk87ceRDHiLvAiOCPmoPMpWH1jdEknl23b0n/WxHoe/20Ur8Unlb/GIBNIKE2oi2 Sf/Q== X-Gm-Message-State: AOAM5305WPO3YUSOlQWvfcQJsjGHZWPA5u1agGlEW50A8d2NskuF9Es2 QqQLXZoOTy6lpZ82g1YhSpA= X-Google-Smtp-Source: ABdhPJyoKd/LvymeWNh2wfywlSPPy2avV6Ze/cSKPN6uDF2nbFtZR8U0RTnkX9pEOhwnWBl1FJR2AA== X-Received: by 2002:a05:600c:21ca:: with SMTP id x10mr1667897wmj.63.1594853008678; Wed, 15 Jul 2020 15:43:28 -0700 (PDT) Received: from [192.168.1.3] (ip68-111-84-250.oc.oc.cox.net. [68.111.84.250]) by smtp.gmail.com with ESMTPSA id b18sm5676558wrs.46.2020.07.15.15.43.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jul 2020 15:43:27 -0700 (PDT) Subject: Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call To: Daniele Alessandrelli , Sudeep Holla , linux-arm-kernel@lists.infradead.org References: <20200715165518.57558-1-daniele.alessandrelli@linux.intel.com> From: Florian Fainelli Message-ID: <5f74221b-aec7-7715-19d1-5cbb406f1bdc@gmail.com> Date: Wed, 15 Jul 2020 15:43:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200715165518.57558-1-daniele.alessandrelli@linux.intel.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200715_184331_122243_5E304A64 X-CRM114-Status: GOOD ( 29.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-kernel@vger.kernel.org, Peng Fan , "Paul J. Murphy" , Daniele Alessandrelli , "Paul J. Murphy" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote: > From: Daniele Alessandrelli > > 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 > Signed-off-by: Paul J. Murphy > --- > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel