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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 A7D0EC433C1 for ; Tue, 30 Mar 2021 15:04:42 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 31F1861957 for ; Tue, 30 Mar 2021 15:04:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 31F1861957 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=nWNt4Izb0B2HX5ZMbTzwVxDhAsuvDhJjquvG2K3rAJY=; b=EKYu/wFbkTH6cZ9rNVCLEfN2X zKqZZZDsJzWq+krBXA+lWbZ8BAjzj0wruGwGKismiT7OO8J9IfUaujny5I4gYRkw/QWPykZdz2zL/ 1bJ42hNzGWYubN12XfofdXT3rY7uKwh0+/SbaWEbpJrAZEClNWcIQbbp/FGhBoIv3Lbcjg0a44Fo8 bjB67OP1GJvlDkwKr0BO/qSLgEaMJYsZF71oamC22fpJQSpzvdoiF+/3UKL6G6raW6o2OuejYMZqQ WEz5Gc6+jKG1AEkjbk2gUoK24yQsR9H9JlcENi5hxXLj08zrYJmMKzse/+ALqiKC3zGgSz8+sfA4i PVWy3KF4w==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lRFts-0045g1-1d; Tue, 30 Mar 2021 15:03:24 +0000 Received: from mail-oo1-f54.google.com ([209.85.161.54]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lRFtn-0045fV-GL for linux-arm-kernel@lists.infradead.org; Tue, 30 Mar 2021 15:03:21 +0000 Received: by mail-oo1-f54.google.com with SMTP id c12-20020a4ae24c0000b02901bad05f40e4so3841388oot.4 for ; Tue, 30 Mar 2021 08:03:19 -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=hkcxsKobvrXM94axutkD7tUW99AtfQR2Q4kV4/h1TzdQSAB+6jRkE6eg55dyD1AZ8J X/8GUUb3gT3HGPzUaUmvf8jxq29olog81Ir7zPPUN1noeuuCOir5C1y2DFuHz8CvSyKj 084sBcsZ/2T8CTET6RLEggvEFDYHUAbwXBJJWOy8SQZdXG33hIavwyXBqdd+vG19YUT2 xw5OBbfiAK5zcX122iwapKkcztServrj1HfZoViXQQfmLH3bcT4Q4ZKjvvnUFPMbA56c I9UmfEftq3xEZ1rZ5dnbD0DrF4p22wDf9mxZranW6QTZTVfoFljHlQ3r8qxNvoWiJ1ik /T+Q== X-Gm-Message-State: AOAM5327AWhdCLpVi+c7++vq590KrVIXwPj2NflV0r9/nZndVOIST8Zc VMBcFibjpHY3kE7aWHctRg== 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210330_160319_610382_3BE393D6 X-CRM114-Status: GOOD ( 30.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel