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 6FC1FC38142 for ; Mon, 23 Jan 2023 15:43:30 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3F38A8577F; Mon, 23 Jan 2023 16:42:23 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="XOmwBXFK"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B719485753; Mon, 23 Jan 2023 16:14:06 +0100 (CET) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E8E2985753 for ; Mon, 23 Jan 2023 16:13:50 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=robh@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1AB1C60F63 for ; Mon, 23 Jan 2023 15:13:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82394C4339C for ; Mon, 23 Jan 2023 15:13:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674486828; bh=EUJJ2u7kqRMIx6GY9GfIaYyC5O4aTFGMhejAOo4BYg0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XOmwBXFKwBnlIOG61uwdM2bjOMssZiQMMf9uYTTOt8i7oK7PcV/EDGBg1UueKrOhs Nf4cbpF0/QZGH9CD83pXMrlQ0DNPCWBjiua7N4BJQ4EGoBGD+9NnbKPPZvnNjgYgyc HWn8Em8AAljOKcgicKbypvz7xWAU3Q0OC//oVxyT6Z0o8s1M9qS6pCfQxvEW4iETxr qVsbc+CoGMmxJDcEzkaHPCAyBXVPeQZ1CcBdv2zqAy5zKHlM1E8a8r8RVNhJVg43Tv YgFab0ooLk1N5Em45HifzeF2ZC/pJgW+0tGWtneFGJGUBuAxEI87CtyE0HkMUujA/b uzrRljDLePvxA== Received: by mail-vs1-f47.google.com with SMTP id n190so13187512vsc.11 for ; Mon, 23 Jan 2023 07:13:48 -0800 (PST) X-Gm-Message-State: AFqh2kq9AS3HvXIineFNZazksfuFw/Q2MflZ7R40flfuGzuo+t1VBr/3 3/m7KPOUROzV57qKUaTMr+w7b82llWzfMSARBg== X-Google-Smtp-Source: AMrXdXv6wlc6o5jTBufi1fwaNczRvOoM9cVtnD8+hKUUnTe/XQkjMJukt2cFRta//4/rEwK9FquS43VPCNHJiC8lxYE= X-Received: by 2002:a67:ef8a:0:b0:3d0:b955:e0af with SMTP id r10-20020a67ef8a000000b003d0b955e0afmr3497460vsp.26.1674486827329; Mon, 23 Jan 2023 07:13:47 -0800 (PST) MIME-Version: 1.0 References: <20221219111251.GA22370@e121910.cambridge.arm.com> <20230118124923.GB631605@bill-the-cat> <20230118135932.GC631605@bill-the-cat> <20230119163157.GA18384@e121910.cambridge.arm.com> In-Reply-To: From: Rob Herring Date: Mon, 23 Jan 2023 09:13:35 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver To: Simon Glass Cc: Abdellatif El Khlifi , trini@konsulko.com, achin.gupta@arm.com, xueliang.zhong@arm.com, Drew.Reed@arm.com, sudeep.holla@arm.com, jens.wiklander@linaro.org, ilias.apalodimas@linaro.org, nd@arm.com, u-boot@lists.denx.de Content-Type: text/plain; charset="UTF-8" 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 Fri, Jan 20, 2023 at 4:04 PM Simon Glass wrote: > > Hi Rob, > > On Thu, 19 Jan 2023 at 11:11, Rob Herring wrote: > > > > On Thu, Jan 19, 2023 at 10:41 AM Simon Glass wrote: > > > > > > Hi Abdellatif, > > > > > > 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 wrote: > > > > > > > > > > > > > > > > > > > > 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 discovery > > > > > > > method every time? > > > > > > > > > > > > > > > > > > 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 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 even > > > > > > 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 mechanism 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 portion > > > > > > > be in the device tree. To which it sounds like your answer is "not in > > > > > > > the device tree". > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > 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 unnecessary > > > > > > 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 getting 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 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 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. > > > > > > 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). > > > > We already have that. It's just called 'arm,psci'. FF-A is not the > > top-level thing. SMCCC is. That's unfortunately called PSCI in DT > > because SMCCC grew out of PSCI. Evolution is ugly... > > > > It's like this: > > > > SMCCC > > +--PSCI > > +--TRNG > > +--FF-A > > +--SCMI (sometimes) > > +--OP-TEE > > +--...Whatever Arm comes up with next... > > OK well that sounds OK. > > So what is the problem here? We have an SMCCC top-level thing in the > DT and everything else can be bound from that, right? Are people on > this thread not aware of this...or am I still missing something? > > Can you point to the SMCCC driver in U-Boot? Is this > bind_smccc_features(), i.w.c. it looks like it does what I want...why > does this thread exist? I imagine the u-boot structure for all this has evolved like the bindings where each feature was developed independently. From my brief look at it, initialization of all the above features would need to be reworked to work as described. Rob