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 EBBC7C00144 for ; Tue, 2 Aug 2022 03:08:19 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 9AAE281115; Tue, 2 Aug 2022 05:08:17 +0200 (CEST) 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="LoM7u7+e"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 63EB883FA5; Tue, 2 Aug 2022 05:08:16 +0200 (CEST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 488008110C for ; Tue, 2 Aug 2022 05:08:13 +0200 (CEST) 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-vs1-xe2c.google.com with SMTP id x125so13229103vsb.13 for ; Mon, 01 Aug 2022 20:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v8uEHVpVPcyWRNglIqHAkVxFAI6WMAQOQ26znzI+QyE=; b=LoM7u7+e1Ut3Bsn7Sf/abIjkDIIrCh67joTmToW9WSuokBgW0mbcVXrpKPY0rB08x0 fDEMBn7wn4uo+HyNSIU3z2H7t9SBNb17j4vnDPc3vp3BdZCoHXtrGeVbw8bkWxFxmF79 DPkB1H6Kj6yTCc0sN1sd/wNnxm0+kwcX9U6rY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v8uEHVpVPcyWRNglIqHAkVxFAI6WMAQOQ26znzI+QyE=; b=EIxb5ADnfTCgZ6xhaGB8t5ZnMokJrwEjv14I0IgegFW5Q3DyFS0qqvyqUf0VndA1B5 rfJ6e8UJpGUjPEsvJHvjv0gHU2J2RGSWc/42/VuBbFRlznC/96JKTvfpRwDveYEfbIi1 NC4AT6D4ccI3SQtBCBqKu/DbUG590G6FDIm8IrYGHvWcV+87jVa2LrmXt815aJcT9UH8 A44PDgFGTh/H0wM9hp77d7TGKoJmU3tt6Uqhvv4Evwvq9+cwqs4Dwq6xAOS+Pmk2/UE/ s15uypnHhHeWfwMuVn6Hm6tn8upN5Q0SzpyrwxBByk3gm4pSWPVgGgOxgDV+31ZechKS g+Tg== X-Gm-Message-State: AJIora+VT2cNnm/D29c8LNY8U7ufCPXBFkvXjsQt3EQhuIF/Vs31j9pT ixeCN5fw0ho/kjP2bWgGO06xP8tWOR3SXzawPuDnCQ== X-Google-Smtp-Source: AGRyM1vutxajiWA515SYt2J8vUWDp2mHpwBE/y6yKQV08rDYgmqfTg+RneH1vsar7fRS0LCZbqW+FOmWKy7AS1BRZk4= X-Received: by 2002:a05:6102:1517:b0:358:4b7a:70d4 with SMTP id f23-20020a056102151700b003584b7a70d4mr7637411vsv.19.1659409691774; Mon, 01 Aug 2022 20:08:11 -0700 (PDT) MIME-Version: 1.0 References: <20220329151659.16894-1-abdellatif.elkhlifi@arm.com> <20220406194711.GN14282@bill-the-cat> <20220407125424.GA32742@e121910.cambridge.arm.com> <20220407125811.GO14282@bill-the-cat> <20220412114315.GA18372@e121910.cambridge.arm.com> <20220412120106.GH14282@bill-the-cat> <20220413142023.GA23999@e121910.cambridge.arm.com> <20220413164607.GU14282@bill-the-cat> <20220801192808.ego5wxtx7gi5ncdl@bogus> In-Reply-To: <20220801192808.ego5wxtx7gi5ncdl@bogus> From: Simon Glass Date: Mon, 1 Aug 2022 21:08:00 -0600 Message-ID: Subject: Re: [PATCH 0/6] introduce Arm FF-A support To: Sudeep Holla Cc: Tom Rini , Abdellatif El Khlifi , Rob Herring , ". Ilias Apalodimas" , achin.gupta@arm.com, Rui Miguel Silva , vishnu.banavath@arm.com, xueliang.zhong@arm.com, U-Boot Mailing List 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 Sudeep, On Mon, 1 Aug 2022 at 13:28, Sudeep Holla wrote: > > On Mon, Aug 01, 2022 at 01:13:23PM -0600, Simon Glass wrote: > > On Wed, 13 Apr 2022 at 10:46, Tom Rini wrote: > > > > > > How is it both discoverable and doesn't have a device tree node, in the > > > kernel? > > > > Also, if it is discoverable, we can still use U-Boot to discover it > > and then pass the info to Linux in the DT. > > > > Why ? Linux can discover the presence of the feature with a simple SMCCC > based query. We don't need any DT bindings for this particular feature. > Not sure if you are talking in general or in the context of $subject > feature in the kernel. Oh well my understanding of Open Firmware was that the firmware did the probing and passed the info to the OS. > > > I am seeing several series which don't have 'proper' DT bindings in > > Linux. First I heard it was for legacy reasons, but now I am hearing > > something different. For U-Boot, we really do need to have DT bindings > > for devices. All this ad-hoc creation of stuff makes things hard to > > discover, adds to code size and makes things like of-platdata > > impossible. > > > > I may not have the complete picture here. If you are saying that every > feature in the u-boot needs DT for some reason, then that's U-boot's > limitation or restriction. But just the presence of node means nothing Yes it is something I am becoming more and more concerned about. > until the corresponding feature is queried and confirmed to be present > in the firmware. That is very important as we can't skip the query stage > just because of presence of some DT node for this. > > > Furthermore, if the bindings affect U-Boot, then the U-Boot project > > should have a say in what is being done there, not just be downstream > > of all such changes. > > > > I still think you talking about some issue in general and it doesn't > apply in this case. The new firmware interfaces are designed to be > discoverable which is the main advantage over any non discoverable > hardware and/or firmware interface. One main advantage I see is that we > don't need any DT bindings which makes the firmware upgrades must simpler > as the users can query the interface and know exactly what they need > instead of relying on DT node which may get stale if not updated with the > firmware update. I am not sure if whatever I am writing here is relevant > to what your concerns are as I think I haven't understood them fully. I'm not sure either. In particular I'm not sure why it would be easier to update whatever the FF-A software is than to update the DT, since presumably they are both in the firmware. I am talking about an issue in general and the same issue in particular with this series. Can I suggest resending this series with a change log for each patch. Also please try to avoid #ifdefs and make sure to include documentation in doc/ including how this relates to the UEFI firmware-update effort that ARM/Linaro is undertaking. Also, what happened to the tests / sandbox driver? Regards, Simon