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 47339C19F28 for ; Wed, 3 Aug 2022 10:14:43 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E337C841AB; Wed, 3 Aug 2022 12:14:40 +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 8F070841DF; Wed, 3 Aug 2022 12:14:39 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id D3D00810E8 for ; Wed, 3 Aug 2022 12:14:35 +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=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 DC5B3113E; Wed, 3 Aug 2022 03:14:35 -0700 (PDT) Received: from e121910.cambridge.arm.com (unknown [10.57.12.206]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 097213F67D; Wed, 3 Aug 2022 03:14:31 -0700 (PDT) Date: Wed, 3 Aug 2022 11:14:12 +0100 From: Abdellatif El Khlifi To: Tom Rini Cc: Sudeep Holla , Simon Glass , Rob Herring , ". Ilias Apalodimas" , achin.gupta@arm.com, vishnu.banavath@arm.com, xueliang.zhong@arm.com, U-Boot Mailing List , nd@arm.com Subject: Re: [PATCH 0/6] introduce Arm FF-A support Message-ID: <20220803101412.GA5506@e121910.cambridge.arm.com> 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> <20220802122219.GH1146598@bill-the-cat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220802122219.GH1146598@bill-the-cat> 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, Aug 02, 2022 at 08:22:19AM -0400, Tom Rini wrote: > On Mon, Aug 01, 2022 at 08:28:08PM +0100, Sudeep Holla wrote: > > On Mon, Aug 01, 2022 at 01:13:23PM -0600, Simon Glass wrote: > > > On Wed, 13 Apr 2022 at 10:46, Tom Rini wrote: > > > > > > > > How is it both discoverable and doesn't have a device tree node, in the > > > > kernel? > > > > > > Also, if it is discoverable, we can still use U-Boot to discover it > > > and then pass the info to Linux in the DT. > > > > > > > Why ? Linux can discover the presence of the feature with a simple SMCCC > > based query. We don't need any DT bindings for this particular feature. > > Not sure if you are talking in general or in the context of $subject > > feature in the kernel. > > > > > I am seeing several series which don't have 'proper' DT bindings in > > > Linux. First I heard it was for legacy reasons, but now I am hearing > > > something different. For U-Boot, we really do need to have DT bindings > > > for devices. All this ad-hoc creation of stuff makes things hard to > > > discover, adds to code size and makes things like of-platdata > > > impossible. > > > > > > > I may not have the complete picture here. If you are saying that every > > feature in the u-boot needs DT for some reason, then that's U-boot's > > limitation or restriction. But just the presence of node means nothing > > until the corresponding feature is queried and confirmed to be present > > in the firmware. That is very important as we can't skip the query stage > > just because of presence of some DT node for this. > > > > > Furthermore, if the bindings affect U-Boot, then the U-Boot project > > > should have a say in what is being done there, not just be downstream > > > of all such changes. > > > > > > > I still think you talking about some issue in general and it doesn't > > apply in this case. The new firmware interfaces are designed to be > > discoverable which is the main advantage over any non discoverable > > hardware and/or firmware interface. One main advantage I see is that we > > don't need any DT bindings which makes the firmware upgrades must simpler > > as the users can query the interface and know exactly what they need > > instead of relying on DT node which may get stale if not updated with the > > firmware update. I am not sure if whatever I am writing here is relevant > > to what your concerns are as I think I haven't understood them fully. > > Part of the problem I think here is who does have a more complete > picture of things? Saying there's a DT binding available is generally > the firmware interface for discovering something exists somewhere else > (excepting buses that define a discovery protocol). Except not in this > case where there's a different interface. So who defined that interface > and where is it specified? What's already been accepted upstream to > other projects? > > We're on I think v4 of this series now, and it was this email here that > explained that an SMCCC call is how Linux finds out this exists (or > doesn't exist). > > -- > Tom Hi guys, All your feedbacks are valuable and more than welcome. Thanks for all of you. Sorry for any confusion, I'd like to highlight the following points: 1/ FF-A spec: cover letter v1 already states that this work provides support for Arm Firmware Framework for Armv8-A v1.0 (please see [A]) Also, in the v1 patchset the documentation of the main config enabling the driver states that we are using the FF-A spec and the link is provided: in ARM_FFA_TRANSPORT config: + This driver is based on FF-A specification v1.0 and uses SMC32 + calling convention. + + FF-A specification: + + https://developer.arm.com/documentation/den0077/a/?lang=en Please refer to [B] for more details. 2/ Linux: The linux kernel driver has been referred to for showing that in linux FF-A is considered as a data bus and not just as a FW interface. 3/ FF-A bus discovery in u-boot: In patchset v1 the FF-A bus was probed through a device tree node. Then, we got feedbacks from the device tree maintainer stating this won't be accepted. This is why v2 version comes into the picture by making FF-A bus discoverable using device_{bind, probe} API FF-A bus discovery in u-boot succeeds when all these operations are successful: - querying the FF-A framework version - querying from secure world the u-boot endpoint ID - querying from secure world the supported features of the specified FF-A calls - mapping the RX/TX buffers - querying from secure world all the partitions information These are done at ffa_probe level. +/** + * ffa_probe - The driver probe function + * @dev: the arm_ffa device + * + * Probing is done at boot time and triggered by the uclass device discovery. + * At probe level the following actions are done: + * - setting the conduit + * - querying the FF-A framework version + * - querying from secure world the u-boot endpoint ID + * - querying from secure world the supported features of the specified FF-A calls + * - mapping the RX/TX buffers + * - querying from secure world all the partitions information In patchset v2 , ffa_bus_discover has been introduced and documented in the header (please refer to [D] and check the documentation of the functions: ffa_bus_discover , ffa_probe, ffa_get_device) + /* The FF-A bus discovery succeeds when probing is successful */ + ret = device_probe(ffa_priv_data.dev); 4/ Feedbacks from Linaro: We got new feedbacks from Linaro and we agreed to align the driver interfaces with those used in the kernel driver. Furthermore, we got a new requirement to make the driver independent from EFI. v3 patchset addresses that. 5/ in v3 cover letter, the full history of what each version brings are listed (please see [C]) 6/ A detailed readme document has recently been written and will be added in the upcoming v4 patchset cover letter 1: [A] https://lore.kernel.org/all/20220329151659.16894-1-abdellatif.elkhlifi@arm.com/ kconfig of the driver: [B] https://lore.kernel.org/all/20220329151659.16894-2-abdellatif.elkhlifi@arm.com/#Z31drivers:arm-ffa:Kconfig cover letter 3: [C] https://lore.kernel.org/all/20220801172053.20163-1-abdellatif.elkhlifi@arm.com/ patch introducing FF-A discovery: [D] https://lore.kernel.org/all/20220415122803.16666-2-abdellatif.elkhlifi@arm.com/