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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 71995C433E3 for ; Fri, 17 Jul 2020 09:47: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 3C9942070E for ; Fri, 17 Jul 2020 09:47:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UaDhxeqo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3C9942070E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=bE2oX47Xqo1PkOEdBAiV5YdBvff3lCwTRUSgiomnGCk=; b=UaDhxeqom5+SyItRvnhmjptZT X9HGXzksB1r6J8VUJqmLip85o/ELncbOD9cdKeRjRtuJgkDZEu8mIcrqaT2d1rF3PXtg+WiP8iC7r fljx3yM78wf0gvYTuk67jHyvbWCcs5/Ej4/UPAeTYYk45y916TyuSXx1ppH6LiNBiFPKPi0maVRZH bkra+Xrh50pajRTXVxv74TDWRiymfuGlSVAtLuvIKhbj5TKZ5wd7y8qHF6lInM0TPfI1o+1Sc8C9Y nVoAopKph64aguDE+Vuwi8jI7QMSQ8x/1ytrLZzW4u6pL1qSW7+KqNvWA8yCM/XEqILkBjWIlYwSN wPacG4dVA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jwMwV-0002Rp-Eo; Fri, 17 Jul 2020 09:46:11 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jwMwS-0002Qa-0Y for linux-arm-kernel@lists.infradead.org; Fri, 17 Jul 2020 09:46:08 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9D10830E; Fri, 17 Jul 2020 02:46:04 -0700 (PDT) Received: from bogus (unknown [10.37.8.134]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5B39E3F66E; Fri, 17 Jul 2020 02:46:02 -0700 (PDT) Date: Fri, 17 Jul 2020 10:45:55 +0100 From: Sudeep Holla To: Florian Fainelli Subject: Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call Message-ID: <20200717094555.GA24501@bogus> References: <20200715165518.57558-1-daniele.alessandrelli@linux.intel.com> <5f74221b-aec7-7715-19d1-5cbb406f1bdc@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5f74221b-aec7-7715-19d1-5cbb406f1bdc@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200717_054608_149259_BA7F69B7 X-CRM114-Status: GOOD ( 26.43 ) 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: Peng Fan , "Paul J. Murphy" , linux-kernel@vger.kernel.org, "Paul J. Murphy" , Sudeep Holla , Daniele Alessandrelli , Daniele Alessandrelli , linux-arm-kernel@lists.infradead.org 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 Wed, Jul 15, 2020 at 03:43:24PM -0700, Florian Fainelli wrote: > > > 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? > Good point, I had forgotten about LPAE. Thanks for pointing it out. > 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? > Agreed, we need to add the check for proper return value then and definitely document it very clearly as we are trying to standardise a call to vendor SiP FID space of SMCCC. > 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? > I expect so and this comes as shmem property from DT already. We are just passing the value obtained from there as is. This is just to help TFA or the firmware to identify the specific channel/shmem as SMC/HVC otherwise has no way to do so. > 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? > Yes, but we definitely can't rely on such mechanism in the kernel. It is more a platform choice as they run different bootloaders. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel