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 11770C00A5A for ; Thu, 19 Jan 2023 16:56:22 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C17B88565F; Thu, 19 Jan 2023 17:56:19 +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 ABA1A85668; Thu, 19 Jan 2023 17:56:17 +0100 (CET) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id 8090C85265 for ; Thu, 19 Jan 2023 17:56:14 +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 555F71BA8; Thu, 19 Jan 2023 08:56:55 -0800 (PST) Received: from bogus (unknown [10.57.77.84]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E7D0E3F445; Thu, 19 Jan 2023 08:56:11 -0800 (PST) Date: Thu, 19 Jan 2023 16:56:09 +0000 From: Sudeep Holla To: Simon Glass Cc: Abdellatif El Khlifi , 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, nd@arm.com, u-boot@lists.denx.de, Sudeep Holla Subject: Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver Message-ID: <20230119165609.347dhs2eppn4ukjr@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: 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, (sorry we just crossed the emails) On Thu, Jan 19, 2023 at 09:41:12AM -0700, Simon Glass wrote: > > Can you add a DT node for the 'FF-A SW interfaces' and attach some > sort of top-level driver to that? Perhaps simple-bus, or your own > thing? You don't need to add compatible strings for subnodes (devices > that are discoverable within that). > Thanks for putting this nicely. I just wrote the same thing probably in not so simpler way. But I agree with you as Abdellatif last email talks more around sub-nodes or child device nodes (devices that are discoverable within that) > If you don't want to submit the compatible string to Linux, I will do > it. If it has to have a 'u-boot,' prefix then so be it, but I don't > see why that is necessary, since Linux can ignore it if it likes. > > We have been talking about this for far too long, IMO. Would you like > me to send a patch? It is something like this: > > ff-a { > compatible = "arm,ff-a"; > }; > Makes sense if DT node is the only way. It should be as simple as this and presence of this must not imply presence of FF-A feature on the platform. The driver must check using FFA_VERSION > > > > 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. > > > > A use case is provided which is the EFI MM communication [7]. > > > > ffa_bus_discover() does the following: > > > > - creates, binds and probes the arm_ffa device > > - at probe level, discovery FF-A interfaces are called to try to discover the FF-A framework > > - when all discovery interfaces succeed, probing is successful and FF-A bus is ready to use > > - if one of the discovery interfaces fails, the arm_ffa device is removed from the DM and > > FF-A bus can not be used > > This is not how things are supposed to work in U-Boot. Please read the > documentation which is here: > > https://u-boot.readthedocs.io/en/latest/develop/driver-model/index.html > > So referencing above: > > 1, No, the binding of the ff-a device should happen automatically from the DT > 2. probing ff-a causes the other devices to be bound (as with PCI, > USB, every other bus in U-Boot) > 3. Yes > 4. No, you must not unbind it. It just sits there unprobed and cannot > be used. We might want to have a command that looks at what is wrong > with it. Probing the device should produce an error, as with every > other device in U-Boot > Agreed on all points(assuming DT way here). Especially the last point, there is no point is rolling back if one partion/device initialisation fails or is not bound. -- Regards, Sudeep