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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9276CC433DB for ; Tue, 30 Mar 2021 15:04:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 59D9161957 for ; Tue, 30 Mar 2021 15:04:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232001AbhC3PDq (ORCPT ); Tue, 30 Mar 2021 11:03:46 -0400 Received: from mail-oo1-f46.google.com ([209.85.161.46]:45798 "EHLO mail-oo1-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231743AbhC3PDS (ORCPT ); Tue, 30 Mar 2021 11:03:18 -0400 Received: by mail-oo1-f46.google.com with SMTP id s1-20020a4ac1010000b02901cfd9170ce2so1943978oop.12 for ; Tue, 30 Mar 2021 08:03:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6Dp4fbDfgQXSbK3dORjSxl3stf7+HDKSewMsMy+yev4=; b=OSE9VG/UzZBJyX5pEZ4ya4otDajmI9ThmBmU0oxqSDw+P9kHuRLmNxDBwcnwivjS5u gmzKO6J2hmgy5+KXAyP3C17amjzq6RmaeKRXW18km5OJgEfvqf7Gyk78V3Dw8pByAJxW S5LpZpM/Bg41OFaQhImsLygMlRDtBX5E8FEP1A3+ElMthwO4J3NY1mbWz/Nf4N00Xqf8 8ZD2ulNYhjn1KalsrMlt9oB84uczJmgTL1PGHsjRyESvD2OYhXxknUj2V6mCJmNW+nEg jVr6RBB+fqHNC89lyx56jKfwWl044s0f7kzIY5afk69n3UGO1Hk/gHQd7m9FlBfp6xCc Xumg== X-Gm-Message-State: AOAM531B1UgO2d3t6pP6vI44lUKQ5vJoOWwmmqdKQmWGk8805M2h0N8N X4Cyr47pGNJUztdDATi0KWAHZmagwQ== X-Google-Smtp-Source: ABdhPJwLwUfACLeNd1t7tr9CKm+0h6c7Eu2gtXOrCjmnSCf2IKwaqP8JXQrIZ/50Rm0JkvxYgZc9Kg== X-Received: by 2002:a4a:1ac3:: with SMTP id 186mr7704432oof.8.1617116598075; Tue, 30 Mar 2021 08:03:18 -0700 (PDT) Received: from robh.at.kernel.org ([172.58.99.136]) by smtp.gmail.com with ESMTPSA id h23sm5146227ots.0.2021.03.30.08.03.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Mar 2021 08:03:17 -0700 (PDT) Received: (nullmailer pid 306198 invoked by uid 1000); Tue, 30 Mar 2021 15:03:12 -0000 Date: Tue, 30 Mar 2021 10:03:12 -0500 From: Rob Herring To: Sumit Garg Cc: Sudeep Holla , linux-arm-kernel , Devicetree List , Trilok Soni , arve@android.com, Andrew Walbran , David Hartley , Achin Gupta , Jens Wiklander , Arunachalam Ganapathy , Marc Bonnici Subject: Re: [PATCH v5 1/7] dt-bindings: Arm: Add Firmware Framework for Armv8-A (FF-A) binding Message-ID: <20210330150312.GA284502@robh.at.kernel.org> References: <20210325143255.1532452-1-sudeep.holla@arm.com> <20210325143255.1532452-2-sudeep.holla@arm.com> <20210326105545.44rdcbrumg3q6i7y@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Fri, Mar 26, 2021 at 05:26:52PM +0530, Sumit Garg wrote: > On Fri, 26 Mar 2021 at 16:25, Sudeep Holla wrote: > > > > On Fri, Mar 26, 2021 at 10:35:23AM +0530, Sumit Garg wrote: > > > Hi Sudeep, > > > > > > Apologies for catching up late on this patch-set. > > > > > > On Thu, 25 Mar 2021 at 20:05, Sudeep Holla wrote: > > > > > > > > Since the FF-A v1.0 specification doesn't list the UUID of all the > > > > partitions in the discovery API, we need to specify the UUID of the > > > > partitions that need to be accessed by drivers within the kernel. > > > > > > > > > > Wouldn't we be able to implement auto-discovery of ffa partitions? I > > > think enumeration of ffa partitions on FFA bus should be quite similar > > > to enumeration of TAs on TEE bus (see [1]). Otherwise we need to put > > > these redundant DT entries for every ffa partition which IMHO would > > > bloat up device trees for every platform. > > > > > > > Any suggestions on how to ? Clearly spec doesn't have that provision, I > > had raised this point in the past. Jens has similar concern and he did > > ask the same[1]. As I replied to him in that thread[2]. > > > > I am open to suggestion on how to auto-discover, currently as I see spec > > doesn't support it. > > > > Thanks for sharing links to prior discussions and I can see that > currently spec doesn't support it. But from an implementation > perspective, I can't find any reason that we can't support > auto-discover. Have a look at below proposed simple FFA ABI: > > FFA_LIST_PARTITIONS > > - No input params. > - Returns an array of secure partition UUIDs to which this non-secure > virtual/physical FF-A instance is allowed to communicate with. > > I think with auto-discovery, one of the major benefits is that if the > OEM is using a common platform to cater to multiple use-cases which > rely on different secure partitions then OEM doesn't have to bother > about shipping separate DTs. +1 DT should not be the dumping ground for everything forgotten to be made discoverable. There's not much we can do about h/w, but firmware is different and can be changed. In other threads (e.g. PCI config space SMC calls), fixing in firmware is the proposed answer. So let's do that here. Maybe if there are implementations shipping and changing is too late (yet not too late to use a new binding), then I'd feel differently. But being in a spec or not alone is not enough reason alone to accept this. It's obvious the spec did not have wide enough review. Rob