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 D9FE8C004D4 for ; Thu, 19 Jan 2023 16:47:03 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3F4238566F; Thu, 19 Jan 2023 17:47:01 +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 11F5485665; Thu, 19 Jan 2023 17:47:00 +0100 (CET) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id 6395E85665 for ; Thu, 19 Jan 2023 17:46:57 +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=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 41F25176A; Thu, 19 Jan 2023 08:47:38 -0800 (PST) Received: from bogus (unknown [10.57.77.84]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D50C83F445; Thu, 19 Jan 2023 08:46:54 -0800 (PST) Date: Thu, 19 Jan 2023 16:46:52 +0000 From: Sudeep Holla To: Abdellatif El Khlifi Cc: sjg@chromium.org, trini@konsulko.com, achin.gupta@arm.com, xueliang.zhong@arm.com, Drew.Reed@arm.com, robh@kernel.org, jens.wiklander@linaro.org, ilias.apalodimas@linaro.org, Sudeep Holla , u-boot@lists.denx.de Subject: Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver Message-ID: <20230119164652.llh66rapyqqej63f@bogus> References: <20221219111251.GA22370@e121910.cambridge.arm.com> <20230118124923.GB631605@bill-the-cat> <20230118135932.GC631605@bill-the-cat> <20230119163157.GA18384@e121910.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230119163157.GA18384@e121910.cambridge.arm.com> 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 Abdellatif, On Thu, Jan 19, 2023 at 04:31:57PM +0000, Abdellatif El Khlifi wrote: > > Hi Simon, Tom, > > The FF-A transport is a SW bus and is not associated to any HW peripheral or > undiscoverable base address. > > There is only 1 way of discovering the FF-A bus and it's through the FF-A SW > interfaces. The FF-A spec [1] describes this in details. > > Discovering means gathering information about the FF-A framework such as: > the FF-A version, supported features, secure partitions number and attributes. > > Please refer to the following paragraphs for more details: [2], [3], [4], [5] > > The core driver provided by this patchset implements the Setup and discovery interfaces > in addition to direct messaging. > > The driver provides ffa_bus_discover() API that allows to discover the FF-A bus > as described by the spec and in the FF-A driver readme [6]. > > We expect and highly recommend FF-A users to always discover the FF-A bus using ffa_bus_discover() API. > Thanks for the details. But IIRC this discussion is not about the FF-A bus and device(partitions) discovery, but the support for FF-A itself. The discussion is about where to have a device node to represent the existence of FF-A support on a platform. If we are talking about individual partitions (devices) in the device tree, then that is pure stupidity as it goes out of since with the firmware the moment a partition is added or removed in the firmware. IIUC, the whole discussion was around whether to use FFA_VERSION as the discovery mechanism for existence of FF-A support on a platform or you have a device node to specify the same. Just to be clear, even if it is decided to add a device node, the FFA_VERSION must be used to detect the presence of FF-A support and return error otherwise. DT node presence is just to satisfy the design and must be treated as no auto-confirmation for the presence of FF-A support. We are just arguing the device node presence is just redundant, but as mentioned before it is up to U-Boot community to make a call on what is best. -- Regards, Sudeep