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 EE35CC47090 for ; Tue, 6 Dec 2022 04:18:21 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id F0F578527C; Tue, 6 Dec 2022 05:18:18 +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="TO5Snadd"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D3DBD852B1; Tue, 6 Dec 2022 05:18:16 +0100 (CET) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 1DCDC8521B for ; Tue, 6 Dec 2022 05:18:14 +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=jwerner@google.com Received: by mail-wr1-x42c.google.com with SMTP id h7so15756475wrs.6 for ; Mon, 05 Dec 2022 20:18:14 -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=TC5SoZBP5vYWtyOPcVKC+Q/tf3NDzs5w7UK13+LRTCw=; b=TO5SnaddmTTOnJbcR2QK5OQfoZoazl5gufpsyDxrOA9JqEy/SjN3uHCGKVESLX2uZI dtNF8zmGYxIiEBc2KBohwfFAf1JHhB8cgjRICi5AmjZitqDL5iN03+CrX03g/5w+ZSZu fIuWjS0BsX0GxZ1rGHp0WY3FMgUqW6w3ckoNA= 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=TC5SoZBP5vYWtyOPcVKC+Q/tf3NDzs5w7UK13+LRTCw=; b=yeZFuhvw77nU6H4JEE7mG1kUayp5u5qfxG9CgPkw6NXxwXUIwZC7HVXmO4Q9XXh+5b Nv1ADUDPU1HYZdjVrNSsXQBtfKB4+L+uzyDEHq2Z5bUWuXrXlEnQtw19tBZNrjjWHfbS wFZFwItGyBCsQDrZCtx3KbeUjs/1SLO5uNWsj0+hbyixvp2+UpnVOZzcjchIcBpOways uWznymggm1x6bBDw8DZIkWFRcwL/pX5eTe8M6ymrS/mA5I4NI4wWLdmFJ7bMmVRhQD8g MYY63VUwTYDF0HLJzaCi1NF/isB4Vd7XBDOq1uabXgohELdMX1GahKCRqxxeqJ+zVO3s jz5Q== X-Gm-Message-State: ANoB5pm126Pzs9TPA0OC+STj7D1zT31fZmkVdPHnoZMA9Jfiard7qYwv p1s2GVU1IjnemG63UGhWdRjj/D9AjxQ8qF8ozkYRiA== X-Google-Smtp-Source: AA0mqf6ZqiYdgftKXbdnfSITC1THxj68UGR8w8QC1lUUkBjMw2RQk+91zu/7YbuaLxkjyajg6dfkAUU6jI6/weTxRT4= X-Received: by 2002:adf:f7c5:0:b0:242:9e8:84b8 with SMTP id a5-20020adff7c5000000b0024209e884b8mr28166488wrq.25.1670300293462; Mon, 05 Dec 2022 20:18:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Julius Werner Date: Mon, 5 Dec 2022 20:18:00 -0800 Message-ID: Subject: Re: [TF-A] [RFC] Proposed location to host the firmware handoff specification. To: Simon Glass Cc: Dan Handley , Julius Werner , Jose Marinho , "tf-a@lists.trustedfirmware.org" , "u-boot@lists.denx.de" , "boot-architecture@lists.linaro.org" , Manish Pandey2 , Joanna Farley , Ilias Apalodimas , Matteo Carlini , Rob Herring , "Harb Abdulhamid (harb@amperecomputing.com)" , Sivasakthivel Nainar , Samer El-Haj-Mahmoud , nd 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 It seems like some of us still have very different opinions about how this handoff structure should and shouldn't be used, which I really think need to be worked out and then codified in the spec before we can call the document final, because otherwise no firmware project can trust that it is safe to adopt this. My understanding was that this is supposed to be a universal handoff structure that's free to be used by any open source firmware project for any of its internal purposes at any stage of the boot flow as a standalone solution that doesn't force them to pull in dependencies to any other format. If that is the case then I think the spec should reflect this very clearly and should particularly not contain any language about deferring certain types of data to other handoff structures wrapped in the TL. It needs to be clear that projects will be allowed to freely register tags for their needs without the risk of suddenly getting told by the maintainers that they need to use an FDT for this or that instead. On the other hand, if this is just supposed to be an early boot flow extension to FDTs, then that's very different from what I understood the goal to be and then I think the text of the spec should be honest about that front and center. In that case, I wouldn't expect much adoption beyond the ecosystem that's already deeply tied to FDT to begin with, though, and that would be far from "universal".