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 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 705CBC00140 for ; Tue, 2 Aug 2022 08:38:19 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id AE3A383445; Tue, 2 Aug 2022 10:38:17 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id ADA3E83AD1; Tue, 2 Aug 2022 10:38:15 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id 5DA3D81DAB for ; Tue, 2 Aug 2022 10:38:13 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sudeep.holla@arm.com 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 497E4139F; Tue, 2 Aug 2022 01:38:13 -0700 (PDT) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4C0613F73B; Tue, 2 Aug 2022 01:38:11 -0700 (PDT) Date: Tue, 2 Aug 2022 09:38:08 +0100 From: Sudeep Holla To: Simon Glass Cc: Tom Rini , Abdellatif El Khlifi , Rob Herring , Ilias Apalodimas , achin.gupta@arm.com, Rui Miguel Silva , vishnu.banavath@arm.com, xueliang.zhong@arm.com, U-Boot Mailing List Subject: Re: [PATCH 0/6] introduce Arm FF-A support Message-ID: <20220802083808.we6iiqy44u3xlosz@bogus> References: <20220407125424.GA32742@e121910.cambridge.arm.com> <20220407125811.GO14282@bill-the-cat> <20220412114315.GA18372@e121910.cambridge.arm.com> <20220412120106.GH14282@bill-the-cat> <20220413142023.GA23999@e121910.cambridge.arm.com> <20220413164607.GU14282@bill-the-cat> <20220801192808.ego5wxtx7gi5ncdl@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean Hi Simon, On Mon, Aug 01, 2022 at 09:08:00PM -0600, Simon Glass wrote: > Hi Sudeep, > > I'm not sure either. In particular I'm not sure why it would be easier > to update whatever the FF-A software is than to update the DT, since > presumably they are both in the firmware. > No, that is not the point. Someone who integrates must be aware of the fact that since the firmware is updated, there is a dependency(though created unnecessarily in this case) to even update the DT. Missing that may result in spending time and finding it hard way. It may not happen often but still happens and worth saving time and effort if this unneeded dependency is wasn't there. > I am talking about an issue in general and the same issue in > particular with this series. > Since I might be missing to fully understand the issue, I may not be of much help I am afraid. > Can I suggest resending this series with a change log for each patch. > Also please try to avoid #ifdefs and make sure to include > documentation in doc/ including how this relates to the UEFI > firmware-update effort that ARM/Linaro is undertaking. Also, what > happened to the tests / sandbox driver? To give a extremely brief summary on FF-A, it is an interface that enables standard way of communication between different partitions in the system. Partitions(also referred as VMs sometimes) can be either secure or non-secure. Though it can be use to communicate between 2 non-secure VMs, it is unlikely to be use there as it is not arch agnostic. So it will be mainly used between secure and non-secure partitions and amongst secure partitions. -- Regards, Sudeep