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 151BAC00A5A for ; Thu, 19 Jan 2023 16:43:19 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id A2DF285665; Thu, 19 Jan 2023 17:43:16 +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="k0HFZipa"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C790185665; Thu, 19 Jan 2023 17:43:14 +0100 (CET) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 D797985657 for ; Thu, 19 Jan 2023 17:43:11 +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-vk1-xa2f.google.com with SMTP id 22so447803vkn.2 for ; Thu, 19 Jan 2023 08:43:11 -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=iZJb+FuBABQ+1x4SPFpTudauUOD2ey5w+9k44VTMhAU=; b=k0HFZipawnQtbcLNO6j9IePxa043esCMeIk8Cz+JYQdOfqDxZEcCsIbcIZDjqyIMHf mexvw1rMdHjkOG4JVDNS0G/7fjC2c+pACFcH51wbG3/vGzIgXL3Q+z676J9onVH9A5RH DOQe+Dwa704QvT0UtAP4hUcy0N61XwB+tTA0Q= 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=iZJb+FuBABQ+1x4SPFpTudauUOD2ey5w+9k44VTMhAU=; b=yJpToiL1N3Y7Bg6cOUVamtk9OKR53mbRDOcGZp0CMiy9M2n7wNEm2gdSpqZ3tTFi0x 9K6zhn5cH1RAGtalV9P8N7P0jeLRH0w55Wxnd71ftQVvJoa6MuSiE9KMxSAPnxfmUWfr YUCN9igj4uhuQqOQVL7Yc8G9AF2i/35Ei56k2j61QOjprlPLpbbP+SRqZ2sNkmnU0YEa oGLD5xYsLtGkaptlJ5cxQJev8AmYCUMznyEVxNyz39iRoRnNh9eB4Khliab8aXT7EGHn y7Q7Shhz80rwrcZHIDpKaSf6stwGUWl5SXb+kXQWChsGxb2NlINvCekSEPVuFHmVn37H CoKw== X-Gm-Message-State: AFqh2kok+1k54wdxY1CScQdPq+qBJ8nJ4b6XYARuCjAuW7U92HT/m0GM b1SE+1f4yoXsoJy339qkTJTCBg== X-Google-Smtp-Source: AMrXdXvDZA0buR2ZQY9sFA1FzAuBHngDWgbBYH14OV2s9Jcg2+x4PUH0niKuxHCSxJ4EvNtHeXfqKw== X-Received: by 2002:a05:6122:e15:b0:3d5:42a9:94ff with SMTP id bk21-20020a0561220e1500b003d542a994ffmr6560436vkb.13.1674146590525; Thu, 19 Jan 2023 08:43:10 -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 t2-20020a05620a450200b006fba0a389a4sm3643605qkp.88.2023.01.19.08.43.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Jan 2023 08:43:10 -0800 (PST) Date: Thu, 19 Jan 2023 11:43:08 -0500 From: Tom Rini To: Simon Glass Cc: Abdellatif El Khlifi , 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: <20230119164308.GF631605@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="SSQrXjJAjSvYS5Wm" Content-Disposition: inline In-Reply-To: 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 --SSQrXjJAjSvYS5Wm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 19, 2023 at 09:41:12AM -0700, Simon Glass wrote: > Hi Abdellatif, >=20 > On Thu, 19 Jan 2023 at 09:32, 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 wrot= e: > > > > > > > > > > > > > > I guess the problem comes down to, can we have one discovery meth= od that > > > > > everyone shares, or do we have to let everyone invent a new disco= very > > > > > method every time? > > > > > > > > > > > > No one needs to invent any discovery method every time if the firmw= are > > > > specification > > > > provides one and as Rob mentioned many times in the thread, all new= firmware > > > > specification must provide one and we are trying to make sure that = is > > > > the case with all new > > > > specs from Arm. > > > > > > > > > > > > > FF-A, Op-tee, U-Boot, coreboot, barebox (and > > > > > everyone else I'm unintentionally forgetting) could just discover= these > > > > > things via device tree. > > > > > > > > > > > > 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 e= ven > > > > discussing > > > > an alternative method here. > > > > > > > > > > > > > Or, we could all write our own code to perform > > > > > the discovery. > > > > > > > > > > > > For what reason ? I can understand if there is no discovery mechani= sm but > > > > that's not the > > > > case in $subject. > > > > > > > > > > > > > And when RISC-V comes along with similar functionality, > > > > > we could probe their device tree and see they've implemented the = same > > > > > concept, but a little differently, but still have the discovery p= ortion > > > > > be in the device tree. To which it sounds like your answer is "no= t in > > > > > the device tree". > > > > > > > > > > > > > I see U-boot seem to have made a decision to create DT node for eac= h 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. > > > > > > > > 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 unnec= essary > > > > addition of DT nodes for all the f/w i/f on all the platforms that = need the > > > > support when > > > > one can be just discovered. > > > > > > > > Sorry for the sudden appearance on this thread, I was avoiding gett= ing 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 yo= u and > > > > other U-boot > > > > maintainers and the community in general to decide the right course= in this > > > > case. > > > > > > 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. > > > > Hi Simon, Tom, > > > > The FF-A transport is a SW bus and is not associated to any HW peripher= al 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. >=20 > 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). >=20 > 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. >=20 > We have been talking about this for far too long, IMO. Would you like > me to send a patch? It is something like this: >=20 > ff-a { > compatible =3D "arm,ff-a"; > }; No, we don't need a DT node here. Everyone else is insisting that we can solve the problems without it. So, lets go ahead and prove it. The approach they're describing can be integrated without a device tree node, in to the rest of the framework we have. --=20 Tom --SSQrXjJAjSvYS5Wm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmPJcxwACgkQFHw5/5Y0 tyyKAAv/QavVLzPE8al3Xqfmz0bEcH/+7VIXU0idktnu1dkcvzQTEPLVsDTij5Op uCVuTXHA70vxlbxG1UQ+y9P1xtPZ8RD6LzTxpLMQla/HmEqgHl/BkGtJ2ZUoKmtJ ae83g9KdgAOtZ3NlVi/BiakkMOT18sJTOREwdkgM9yG7edh++aplNesDTMJGE6Rd l0ZUKqTQ68QwCTFLeQ8pNRdE+Nf4ByayUh0gV08LoJke2wBxOU7y6XE5jAli63vS Aw7FjbAizz5qTmFBcdbWVbfrcGgbilocqKp9VZywjNOugL3bjbEJWCVSQ9J1FSmu 2vp1JpZYYnKzt4YQNssV3c/bS9jzK9yVmi94QbTZZuXFsLWUlOJPlCeOsW0nDKdt SDTpA3tUhfPcWzU+1ae6+yV4hlqgMdR8SptnrxsiEixZnmduTWGsSE+Gz6vkoNRW bo7llhmyOdbSF1u3+KxoCSg7bx3N0BJdaCCllGmT73EPvFbZ0oCH0F0jmpty5R3H kYRgwIsH =w08v -----END PGP SIGNATURE----- --SSQrXjJAjSvYS5Wm--