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 87329C4332F for ; Wed, 16 Nov 2022 13:03:24 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 11B01850EE; Wed, 16 Nov 2022 14:03:22 +0100 (CET) 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 552D2851BE; Wed, 16 Nov 2022 14:03:20 +0100 (CET) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id 4CF0985065 for ; Wed, 16 Nov 2022 14:03:17 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=abdellatif.elkhlifi@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 6E0101477; Wed, 16 Nov 2022 05:03:22 -0800 (PST) Received: from e121910.cambridge.arm.com (unknown [10.57.40.250]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 178463F663; Wed, 16 Nov 2022 05:03:14 -0800 (PST) Date: Wed, 16 Nov 2022 13:03:11 +0000 From: Abdellatif El Khlifi To: Simon Glass Cc: u-boot@lists.denx.de, nd@arm.com Subject: Re: [PATCH v3 3/4] arm_ffa: introduce Arm FF-A low-level driver Message-ID: <20221116130311.GA4259@e121910.cambridge.arm.com> References: <20220801172053.20163-1-abdellatif.elkhlifi@arm.com> <20220801172053.20163-4-abdellatif.elkhlifi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) 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 On Tue, Nov 15, 2022 at 08:24:24AM -0700, Simon Glass wrote: > Hi, > > On Mon, 1 Aug 2022 at 11:21, Abdellatif El Khlifi > wrote: > > > > Add the driver implementing Arm Firmware Framework for Armv8-A v1.0 > > > > The Firmware Framework for Arm A-profile processors (FF-A) > > describes interfaces (ABIs) that standardize communication > > between the Secure World and Normal World leveraging TrustZone > > technology. > > > > This driver uses 64-bit registers as per SMCCCv1.2 spec and comes > > on top of the SMCCC layer. The driver provides the FF-A ABIs needed for > > querying the FF-A framework from the secure world. > > > > 32-bit version of the ABIs is supported and 64-bit version of FFA_RXTX_MAP > > and FFA_MSG_SEND_DIRECT_{REQ, RESP}. > > > > In u-boot FF-A design, FF-A is considered as a discoverable bus. > > The Secure World is considered as one entity to communicate with > > using the FF-A bus. FF-A communication is handled by one device and > > one instance (the bus). This FF-A driver takes care of all the > > interactions between Normal world and Secure World. > > > > The driver exports its operations to be used by upper layers. > > > > Exported operations: > > > > - partition_info_get > > - sync_send_receive > > - rxtx_unmap > > > > This implementation provides an optional feature to copy the driver data > > to EFI runtime area. > > > > Signed-off-by: Abdellatif El Khlifi > > Cc: Tom Rini > > Cc: Ilias Apalodimas > > Cc: Jens Wiklander > > --- > > MAINTAINERS | 6 + > > common/board_r.c | 7 + > > drivers/Kconfig | 2 + > > drivers/Makefile | 1 + > > drivers/arm-ffa/Kconfig | 33 + > > drivers/arm-ffa/Makefile | 7 + > > drivers/arm-ffa/arm-ffa-uclass.c | 16 + > > drivers/arm-ffa/arm_ffa_prv.h | 219 ++++ > > drivers/arm-ffa/core.c | 1338 ++++++++++++++++++++ > > drivers/arm-ffa/efi_ffa_runtime_data_mgr.c | 94 ++ > > include/arm_ffa.h | 132 ++ > > include/dm/uclass-id.h | 1 + > > include/uuid.h | 8 + > > lib/efi_loader/efi_boottime.c | 17 + > > lib/uuid.c | 65 + > > 15 files changed, 1946 insertions(+) > > create mode 100644 drivers/arm-ffa/Kconfig > > create mode 100644 drivers/arm-ffa/Makefile > > create mode 100644 drivers/arm-ffa/arm-ffa-uclass.c > > create mode 100644 drivers/arm-ffa/arm_ffa_prv.h > > create mode 100644 drivers/arm-ffa/core.c > > create mode 100644 drivers/arm-ffa/.c > > create mode 100644 include/arm_ffa.h > > Please add something to doc/ so people know what this is. > > Since you are adding a new uclass you need a sandbox driver and tests. > > The driver appears to have no operations, but there is a bus_ops. The > ops should go in the driver, I suspect, and should pass the device as > the first arg. > > Can FFA_ERR_STAT_SUCCESS be 0 so you don't have to sprinkle the code with it? > > Why is it using EFI things? Can this driver only be used with UEFI? I > hope not, if it is an official way of updating firmware. > > Please don't add more things to board_r.c - we are trying to remove > this init over time. If it is a device it should be probed as needed. > > Is there a device tree binding? > > Also should this go in drivers/misc instead of creating a whole new subdir? Hi Simon, thanks for reviewing. All the above comments have already been addressed in the new versions of the patchset. Please refer to the latest version v7 [1]. By the way I'd like to highlight the following: - The FF-A driver documentation is at doc/arch/arm64.ffa.rst, please refer to it since it provides helpful details about the FF-A support in U-Boot - The patchset comes with Sandbox driver and tests [2] - The driver has operations defined in struct ffa_bus_ops (include/arm_ffa.h). ffa_bus_ops_get() gets the ops. All these are in the driver (drivers/firmware/arm-ffa/core.c) - The FF-A bus has only 1 device. No multiple instances. So passing the device doesn't make sense in our case - FFA_ERR_STAT_SUCCESS has been removed and replaced with 0 - The driver is independent from EFI and can be compiled without EFI - FF-A bus discovery has been removed from the initcall level (board_r.c) Discovery is done on demand. Clients can call ffa_bus_discover() when they want to use the FF-A bus. As an example of how clients initiate discovery please refer to the FF-A MM comms client [3]. - As done in the Linux kernel, the FF-A bus doesn't have a device tree binding since there is no peripheral associated with FF-A. At the early stages of this patchset, we double checked with the device tree maintainer and the decision was no device tree for FF-A - The links below are from the U-Boot mailing list mirror in lore.kernel.org Cheers. [1]: https://lore.kernel.org/all/20221107192055.21669-1-abdellatif.elkhlifi@arm.com/ [2]: https://lore.kernel.org/all/20221107192055.21669-7-abdellatif.elkhlifi@arm.com/ https://lore.kernel.org/all/20221107192055.21669-8-abdellatif.elkhlifi@arm.com/ https://lore.kernel.org/all/20221107192055.21669-9-abdellatif.elkhlifi@arm.com/ [3]: https://lore.kernel.org/all/20221107192055.21669-10-abdellatif.elkhlifi@arm.com/ > > Regards, > Simon