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 69564C05027 for ; Mon, 23 Jan 2023 16:32:52 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 83B9F8574F; Mon, 23 Jan 2023 17:32:48 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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=chromium.org header.i=@chromium.org header.b="ATzNvTWK"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 18B2482F69; Mon, 23 Jan 2023 17:32:44 +0100 (CET) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 1293B82F69 for ; Mon, 23 Jan 2023 17:32:41 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-ed1-x530.google.com with SMTP id v5so15254882edc.3 for ; Mon, 23 Jan 2023 08:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Fp3cUGAE9msL89mpIK1WOTXLyfykvnJhaKFFvksaPVY=; b=ATzNvTWKi4Gx+ea5MTD+9saqXlprx91no6VFQR8ld/6PdX/TdlbNBfnzKStZAQpbJ8 y4wBAWtcih3A0GA3xmpB5IcP+taHcf24130an/TB3bO46RMuIR73j8M/gP15JTSZBC00 bjlWpAncaqHdsamUPStRjyFMOaPX268uoOW10= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Fp3cUGAE9msL89mpIK1WOTXLyfykvnJhaKFFvksaPVY=; b=JxuEjWP0REkzTSR+Do2wVq+NdThfkHkd7QsBh0lHGiDe1a1wsENbe/9d/2imxmLqH0 Jwu1CWOR+WoOvAxbbbxeKT0Jrrori+9FcX+Ac3wwHa0v0QmDIrU/TEGYm3AOYkYfYfV6 UYd7GIc803Wb4ItdsmF+9NzFWtFMJPhMs/o9Q88xiHuZyEIPlzTcIcsaQ9jUuD/GT4x5 Y3jBEfVIbuoMwyUm3Ekd1k/0v6UNSC3hN4oDrTiZi2Sy7kLQRKfArFW6Zo3lE/49AR2A kLN58qX7L4Rd7XBgfjYAH2mT8rMWYwzqagJgD6W5+ViAeZnCsTaKpiZ3FCvtWPGCY8pi BfnQ== X-Gm-Message-State: AFqh2kp801UVecrg9U4O7kwcEo1oXSptJRPq2yv8Pwgff3+XmrSpb7uk mXpHfkWniWcNsLmMbSzrLMUaGOIb00ZxkROB5m/grA== X-Google-Smtp-Source: AMrXdXujZXKqgprWTm1zakSYNCuB0bxUDT3djXaRMs7FD2kVnW89ydZopKLXZFjPlp5mcGl/lTvWBQGHGfAuIfQJduY= X-Received: by 2002:a05:6402:2998:b0:46f:a73d:6bd7 with SMTP id eq24-20020a056402299800b0046fa73d6bd7mr3736597edb.93.1674491560118; Mon, 23 Jan 2023 08:32:40 -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: Simon Glass Date: Mon, 23 Jan 2023 09:32:28 -0700 Message-ID: Subject: Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver To: Rob Herring 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 Hi Rob, On Mon, 23 Jan 2023 at 08:13, Rob Herring wrote: > > 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. OK, then perhaps this is making more sense to me now. Abdellatif, can you please look at the above? We should have one top-level node in the DT and have that driver bind the child devices. Regards, Simon