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 4368BC00A5A for ; Thu, 19 Jan 2023 16:40:58 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5326785657; Thu, 19 Jan 2023 17:40:55 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="WyMzkM10"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A78FE854B2; Thu, 19 Jan 2023 17:40:53 +0100 (CET) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 53CEC85665 for ; Thu, 19 Jan 2023 17:40:49 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x832.google.com with SMTP id z9so1982752qtv.5 for ; Thu, 19 Jan 2023 08:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=EttBZGzKGXywr/zpiplRcqwCWhvWgo1o1JZgUmQ5ReA=; b=WyMzkM10d7f04LumOrDYhzNq3B2wTuxt17Rop7svWYcJDoRRdIbtzZeV3dryqRDGdS rETPvTi3+KVKQs0arH3VXU77Ue4E/JllR7j6EeAX/cyrWULP+8B+pwes6Pl+o9znI9hG 1wcQmw5woOmW9cAVADX4NHGFEgJlCAEPtReNM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=EttBZGzKGXywr/zpiplRcqwCWhvWgo1o1JZgUmQ5ReA=; b=Pknt6kda5VaymtcaWDC9oKpEPN4qvOtXfucx3JpBSOUvxeQLt6LO5t7ItYQV81D0Qa Wccxxh1uj9iFIrRQBF7dU7j/BQzq2KY1wBVih1odA7Jken7kMywdhOmGIdXety5V87Gt 2uqg/6s+i+g6sM/kgC2K7XOX4AH/j0O18qKBXKCXUIqKn/F6T+JEnSOKnJJc056IwbBH BH+5L2UcehSvU0A4fEvRlxvNIbWyRWlr/ysR8I5K8UdxtPDdnOsAT9ZWM7ZtTvnzYWG0 3zzdjuig/M7iavMS4IPaFV7o7ZWI6ZSa8akvfgM0v92X+xRXqRL4XIpzegeK1OrGsGE6 roXA== X-Gm-Message-State: AFqh2kqtDHAq3NVD3vIN66U42BuwCF+nvsIDpfdtI3W8Nm91Z9yQ05Cb hNEWTcWxnclEx/M6/woNRXnlpA== X-Google-Smtp-Source: AMrXdXs5fXZY54sVBMM6evgnbCFdtCdFniyt9O0rQV3hUBOSrovYJ1/cQrjuDpSr4j3VyFBVRTwgbg== X-Received: by 2002:ac8:4510:0:b0:3a8:e35:258f with SMTP id q16-20020ac84510000000b003a80e35258fmr15515432qtn.31.1674146447948; Thu, 19 Jan 2023 08:40:47 -0800 (PST) Received: from bill-the-cat (2603-6081-7b00-6400-99bd-1ec8-6b02-61e8.res6.spectrum.com. [2603:6081:7b00:6400:99bd:1ec8:6b02:61e8]) by smtp.gmail.com with ESMTPSA id cb15-20020a05622a1f8f00b003ab43dabfb1sm6300736qtb.55.2023.01.19.08.40.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Jan 2023 08:40:47 -0800 (PST) Date: Thu, 19 Jan 2023 11:40:45 -0500 From: Tom Rini To: Abdellatif El Khlifi Cc: sjg@chromium.org, achin.gupta@arm.com, xueliang.zhong@arm.com, Drew.Reed@arm.com, sudeep.holla@arm.com, robh@kernel.org, jens.wiklander@linaro.org, ilias.apalodimas@linaro.org, nd@arm.com, u-boot@lists.denx.de Subject: Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver Message-ID: <20230119164045.GE631605@bill-the-cat> 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ro1PRY3Rtw8g7IwX" Content-Disposition: inline In-Reply-To: <20230119163157.GA18384@e121910.cambridge.arm.com> X-Clacks-Overhead: GNU Terry Pratchett 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 --Ro1PRY3Rtw8g7IwX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 19, 2023 at 04:31:57PM +0000, Abdellatif El Khlifi wrote: > On Wed, Jan 18, 2023 at 08:59:32AM -0500, Tom Rini wrote: > > On Wed, Jan 18, 2023 at 01:46:54PM +0000, Sudeep Holla wrote: > > > On Wed, Jan 18, 2023 at 12:49 PM Tom Rini wrote: > > >=20 > > > > > > > > I guess the problem comes down to, can we have one discovery method= that > > > > everyone shares, or do we have to let everyone invent a new discove= ry > > > > method every time? > > >=20 > > >=20 > > > No one needs to invent any discovery method every time if the firmware > > > specification > > > provides one and as Rob mentioned many times in the thread, all new f= irmware > > > specification must provide one and we are trying to make sure that is > > > the case with all new > > > specs from Arm. > > >=20 > > >=20 > > > > FF-A, Op-tee, U-Boot, coreboot, barebox (and > > > > everyone else I'm unintentionally forgetting) could just discover t= hese > > > > things via device tree. > > >=20 > > >=20 > > > I leave that to the individual projects to decide and agree but > > > fundamentally if > > > the specification provides a way to discover, not sure why we are even > > > discussing > > > an alternative method here. > > >=20 > > >=20 > > > > Or, we could all write our own code to perform > > > > the discovery. > > >=20 > > >=20 > > > For what reason ? I can understand if there is no discovery mechanism= but > > > that's not the > > > case in $subject. > > >=20 > > >=20 > > > > And when RISC-V comes along with similar functionality, > > > > we could probe their device tree and see they've implemented the sa= me > > > > concept, but a little differently, but still have the discovery por= tion > > > > be in the device tree. To which it sounds like your answer is "not = in > > > > the device tree". > > > > > > >=20 > > > I see U-boot seem to have made a decision to create DT node for each = and > > > everything > > > that needs to be added to DM which seems bit unfortunate but I don't > > > understand the > > > history/motive/background for it but I respect the decision if it is > > > already made. > > >=20 > > > These firmware interfaces are standard on all Arm platforms and can be > > > discovered > > > based on PSCI/SMCCC. Not using the same and use DT node needs unneces= sary > > > addition of DT nodes for all the f/w i/f on all the platforms that ne= ed the > > > support when > > > one can be just discovered. > > >=20 > > > Sorry for the sudden appearance on this thread, I was avoiding gettin= g into > > > this but thought > > > I will at least express my opinion and also the way the firmware > > > specifications from Arm is > > > expected to be evolved from now on. With that I will leave it to you = and > > > other U-boot > > > maintainers and the community in general to decide the right course i= n this > > > case. > >=20 > > To be clear, if the position is that "this is what everyone else will > > use, really" then yes, we'll follow this in U-Boot. >=20 > Hi Simon, Tom, >=20 > The FF-A transport is a SW bus and is not associated to any HW peripheral= or > undiscoverable base address. >=20 > 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. >=20 > Discovering means gathering information about the FF-A framework such as: > the FF-A version, supported features, secure partitions number and attrib= utes. >=20 > Please refer to the following paragraphs for more details: [2], [3], [4],= [5] >=20 > The core driver provided by this patchset implements the Setup and discov= ery interfaces > in addition to direct messaging. >=20 > 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]. >=20 > We expect and highly recommend FF-A users to always discover the FF-A bus= using ffa_bus_discover() API. >=20 > A use case is provided which is the EFI MM communication [7]. >=20 > ffa_bus_discover() does the following: >=20 > - 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 b= us 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 >=20 >=20 > Cheers > Abdellatif >=20 > [1]: FF-A spec version 1.0, https://developer.arm.com/documentation/den00= 77/latest/ >=20 > [2] 2.8 Partition identification and discovery >=20 > All FF-A components can discover the identities and properties of oth= er partitions through the FFA_PARTITION_INFO_GET > interface. Once discovered, the IDs must be used in the messaging int= erfaces to identify the target of a message. >=20 > [3] 4.2.2.2 Buffer discovery and setup >=20 > This version of the Framework enables discovery and setup of RX/TX bu= ffer pairs between FF-A components as > follows. >=20 > ... >=20 > 2. An endpoint could allocate the buffer pair and use the FFA_RXTX_MA= P interface to map it with the > Hypervisor or SPM as applicable. >=20 > [4] 4.2.2.3 Buffer attributes >=20 > An endpoint must discover the minimum size and alignment boundary for= the RX/TX buffers by passing the > function ID of the FFA_RXTX_MAP ABI as input in the FFA_FEATURES inte= rface (see 8.2 FFA_FEATURES). >=20 > [5] 6.1.1 Common compliance requirements >=20 > - It must be possible for the FF-A components at an FF-A instance to = discover the presence and version number > of their Framework implementations through the FFA_VERSION interface = (see 8.1 FFA_VERSION). >=20 > - All FF-A components must implement support for Setup and discovery = interfaces described in Chapter 8 > Setup and discovery interfaces. These interfaces are as follows. >=20 > FFA_VERSION. > FFA_FEATURES. > FFA_RX_RELEASE. > FFA_RXTX_MAP. > FFA_RXTX_UNMAP. > FFA_PARTITION_INFO_GET. > FFA_ID_GET. >=20 > - It must be possible for an FF-A component, at the lower EL at an FF= -A instance to use the FFA_FEATURES > interface (see 8.2 FFA_FEATURES) to discover if an FF-A interface is = implemented by the FF-A component > at the higher EL. >=20 > [6] FF-A support readme: https://lore.kernel.org/all/20221122131751.22747= -4-abdellatif.elkhlifi@arm.com/#Z31doc:arch:arm64.ffa.rst > [7] FF-A MM comms: https://lore.kernel.org/all/20221122131751.22747-10-ab= dellatif.elkhlifi@arm.com/ Since I'm apparently being unclear, let me try again. Yes, fine, for U-Boot, we'll go ahead and accept patches that implement this spec, and not require device tree modifications. But as also I believe been agreed on, this doesn't prevent some other architecture / group from coming along and claiming it has a new unique approach to this problem and so has to re-invent the discoverable software bus wheel. Nor does it prevent some group from inventing a different software defined bus and discovery method and not re-using any of this work, because it too is special and unique and somehow different enough. --=20 Tom --Ro1PRY3Rtw8g7IwX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmPJcooACgkQFHw5/5Y0 tyx1AwwAhrmwwNrYyNaUGjvLvvo2JS6pbDeXxT33ccxIdFHzmsSSiVHbsGYdWphB 3TRRhBHH9pop14MMAW8w9C5U/hK959+J0E4ZWu1TvUTROAfcHWSYCI/K2+2o4Q5f 8ZjUOEfoNmpTNIj81QYDzyeOY4UL0r66cVUiKDlGZ6WVmItso00S8AaxBQIL+tlB fcz4E/UG7gla3kXa0YhXFMJ2pWUNfV+a23mlZhLaGn95r2KVCw38Htc6eLXQJqdj aAvVhAe0Uepq2YhBpMOyuJ9QAqepGOlcEV+m3CpE0vhiIWPLycGhETyK3swYBKQp pI+XL9zNOeHPkx7EZCmcqgUasBekDbEM52XRhBZKYtupXOMrtS3JHpXmWJuolemC Jmb2P2E8PJA5uFDq1Mqhsdd+2Ev//wCptOQhlRwwue7ja16bwbhbNwOt3GycOi1r 7uwT9MhwEtX9VIO7OWCcBmOHPcR1E14+l0ONobfDzkBa1xQzHT05eegnNjIRJB7J qwilEcYL =RcI1 -----END PGP SIGNATURE----- --Ro1PRY3Rtw8g7IwX--