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=-12.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PULL_REQUEST, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 4E183C433F5 for ; Thu, 9 Sep 2021 20:45:25 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id C064F6054F for ; Thu, 9 Sep 2021 20:45:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C064F6054F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5607E83547; Thu, 9 Sep 2021 22:45:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com 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=konsulko.com header.i=@konsulko.com header.b="X059StSo"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A4F7D822D7; Thu, 9 Sep 2021 22:45:19 +0200 (CEST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 BFA5983582 for ; Thu, 9 Sep 2021 22:44:59 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x834.google.com with SMTP id u21so2704038qtw.8 for ; Thu, 09 Sep 2021 13:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=iUPOaYjnGK3bQkKmKUx3puobPIYwZvpS09EtUyDgBcc=; b=X059StSoWZA87/oBknKVwu1jdGkfiyYtGnZxpZM2CewsUGeiJBGw9wk9FblORVcXj+ PzKvC14ZDF2YJFHooKa12LayzfAPP7Untu5tX7zW0BPWSWTSjebrOM4UKAz9cO5De43W 9NSd0pC1X9beoI3BNseaIowLEaRg/GguIQxd8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=iUPOaYjnGK3bQkKmKUx3puobPIYwZvpS09EtUyDgBcc=; b=3LZfHF/ebVtN6LI1LrLjuI66Cy00ELip5/ZP9CKaCh5YMhoBp9JmfRAsX3jF1tCqSc yDm+vxaVxMXY+V2Cj2U9QFDwvROSwxSXlsCTKH5GefyXRnIjle0qjYqasDz8FIliujva 0WR2pw6nKvndAjaLIbqxfGKRPUpeV9lsH7g6XuJd2qBeKHz2g8U+IJqBv87/EigD8fKX ETup0Yz4qFr+o744UHiYrzn3yGtEsShe4hVDbRJaqTcYfwm5OlFmtwZCYs1CRGsst+iJ DBbggGfHiuwCVVZgZcZLh8L4kwY4gvTGbyxpnvvGw1+ivRbpCNEOQLcPeBVL0kzFYVyr qTZg== X-Gm-Message-State: AOAM530PDfihrZ/BNS9UnPao6sFV+SeKrrv05TLYdWCj122FV0ev6ijY 0Mwxpn65AvzzUMMcBqcGEEPfaw== X-Google-Smtp-Source: ABdhPJzHz5JRundEuvUR0cjnECLa6mHspgkZy0dE+jTbNp633JiyN+PYA2A+1fW63em+HwsJnm1NCw== X-Received: by 2002:ac8:5c4f:: with SMTP id j15mr4810446qtj.256.1631220298454; Thu, 09 Sep 2021 13:44:58 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-f91e-f867-d1bc-397d.res6.spectrum.com. [2603:6081:7b01:cbda:f91e:f867:d1bc:397d]) by smtp.gmail.com with ESMTPSA id i18sm2146218qke.103.2021.09.09.13.44.56 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 Sep 2021 13:44:57 -0700 (PDT) Date: Thu, 9 Sep 2021 16:44:55 -0400 From: Tom Rini To: Simon Glass Cc: Heinrich Schuchardt , U-Boot Mailing List , Alexander Graf , Masahisa Kojima , Ilias Apalodimas , AKASHI Takahiro Subject: Re: Pull request for efi-2021-10-rc4 Message-ID: <20210909204455.GH12964@bill-the-cat> References: <20210904130111.GA12964@bill-the-cat> <20210904143722.GD12964@bill-the-cat> <46CAD3CD-41FA-43B9-9099-225711B754E1@gmx.de> <20210904173949.GI12964@bill-the-cat> <8FD4F99B-E1A5-4842-8BB8-EA2749E4761B@gmx.de> <146342ea-08a3-ec4a-535c-5bcecd54675a@gmx.de> <20210909120808.GY12964@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="62ujixhRsxbgxlYW" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.2 at phobos.denx.de X-Virus-Status: Clean --62ujixhRsxbgxlYW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 09, 2021 at 02:08:24PM -0600, Simon Glass wrote: > Hi Tom, >=20 > On Thu, 9 Sept 2021 at 06:08, Tom Rini wrote: > > > > On Thu, Sep 09, 2021 at 12:52:52PM +0200, Heinrich Schuchardt wrote: > > > > > > > > > On 9/9/21 10:56 AM, Simon Glass wrote: > > > > Hi Heinrich, > > > > > > > > On Sat, 4 Sept 2021 at 12:08, Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > > > > > > Am 4. September 2021 19:39:49 MESZ schrieb Tom Rini : > > > > > > On Sat, Sep 04, 2021 at 07:03:48PM +0200, Heinrich Schuchardt w= rote: > > > > > > > > > > > > > > > > > > > > > Am 4. September 2021 16:37:22 MESZ schrieb Tom Rini : > > > > > > > > On Sat, Sep 04, 2021 at 03:08:38PM +0200, Heinrich Schuchar= dt wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 4. September 2021 15:01:11 MESZ schrieb Tom Rini : > > > > > > > > > > On Sat, Sep 04, 2021 at 11:56:47AM +0200, Heinrich Schu= chardt wrote: > > > > > > > > > > > > > > > > > > > > > Dear Tom, > > > > > > > > > > > > > > > > > > > > > > The following changes since commit 94509b79b13e69c209= 199af0757afbde8d2ebd6d: > > > > > > > > > > > > > > > > > > > > > > btrfs: Use default subvolume as filesystem root (2= 021-09-01 10:11:24 > > > > > > > > > > > -0400) > > > > > > > > > > > > > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/custodians/u-boot-ef= i.git > > > > > > > > > > > tags/efi-2021-10-rc4 > > > > > > > > > > > > > > > > > > > > > > for you to fetch changes up to 1dfa494610c5469cc28cf1= f8538abf4be6c00324: > > > > > > > > > > > > > > > > > > > > > > efi_loader: fix efi_tcg2_hash_log_extend_event() p= arameter check > > > > > > > > > > > (2021-09-04 09:15:09 +0200) > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------= ----------- > > > > > > > > > > > Pull request for efi-2021-10-rc4 > > > > > > > > > > > > > > > > > > > > > > Documentation: > > > > > > > > > > > > > > > > > > > > > > Remove invalid reference to configuration variab= le in UEFI doc > > > > > > > > > > > > > > > > > > > > > > UEFI: > > > > > > > > > > > > > > > > > > > > > > Parameter checks for the EFI_TCG2_PROTOCOL > > > > > > > > > > > Improve support of preseeding UEFI variables. > > > > > > > > > > > Correct the calculation of the size of loaded im= ages. > > > > > > > > > > > Allow for UEFI images with zero VirtualSize > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------= ----------- > > > > > > > > > > > Heinrich Schuchardt (5): > > > > > > > > > > > efi_loader: sections with zero VirtualSize > > > > > > > > > > > efi_loader: rounding of image size > > > > > > > > > > > efi_loader: don't load signature database from= file > > > > > > > > > > > efi_loader: efi_auth_var_type for AuditMode, D= eployedMode > > > > > > > > > > > efi_loader: correct determination of secure bo= ot state > > > > > > > > > > > > > > > > > > > > > > Masahisa Kojima (3): > > > > > > > > > > > efi_loader: add missing parameter check for EF= I_TCG2_PROTOCOL api > > > > > > > > > > > efi_loader: fix boot_service_capability_min ca= lculation > > > > > > > > > > > efi_loader: fix efi_tcg2_hash_log_extend_event= () parameter check > > > > > > > > > > > > > > > > > > > > And I don't see Simon's revert in here either. And he = asked you about > > > > > > > > > > that yesterday: > > > > > > > > > > https://lore.kernel.org/r/CAPnjgZ3eRdjF0jb9S-cJK6y+feuy= RyWf0hNkf2triB4DR4UFBQ@mail.gmail.com/ > > > > > > > > > > > > > > > > > > > > So at this point, are you asserting there is nothing to= revert? > > > > > > > > > > > > > > > > > > Never. Simons "revert" is breaking functionality. The con= cept for suporting blobs in devicetrees supplied by a prior bootstage has n= ot been defined yet. > > > > > > > > > > > > > > > > And to be clearer, reverting something that was introduced = in one rc in > > > > > > > > a later rc isn't breaking functionality. U-Boot releases (= well, the > > > > > > > > non-rc ones for sure) are on a very regular schedule. Exte= rnal projects > > > > > > > > may not depend on some feature introduced at -rcN unless th= ey're willing > > > > > > > > to accept that some changes could happen before release. > > > > > > > > > > > > > > > > > > > > > > There is no value delivered by Simon's series. Neither does t= he image get smaller nor does it fix anything. If he wants to enforce a des= ign, it must work for all use cases. But this requires some conceptual work. > > > > > > > > > > > > Yes, and what's the rush to not do the conceptual work? If I r= ecall > > > > > > part of the thread correctly, yes, Simon didn't get his objecti= ons in > > > > > > before the patches were merged, but it was early enough in the = release > > > > > > cycle that taking a step back and reverting was a reasonable re= quest. > > > > > > What he had said wouldn't have changed if he had gotten the ema= il out a > > > > > > few days earlier. > > > > > > > > > > > > So yes, please merge Simon's revert, or post and merge new more= minimal > > > > > > revert that brings things to the same functional end. There are > > > > > > objections to this implementation, and thus far Simon has been > > > > > > responding all of the requests to better clarify all of the rel= ated code > > > > > > and concepts that have been asked of him, so that in the end an > > > > > > implementation that fulfills all of the technical requirements = can be > > > > > > created, that hopefully leaves all parties satisfied. > > > > > > > > > > > > > > > > > > > > > There is nothing wrong with the current code. > > > > > > > > The current code is misconceived and I did go to great effort to > > > > explain that in the 'devicetree' series. > > > > > > > > > > > > > > It is Simon's concept of blobs in devicetrees that is borked in t= hat it ignores QEMU and any board that gets the DT from a prior boot stage. > > > > > > > > That's because I was completely unaware of this strange back-door > > > > approach. It would have helped a lot if someone had bothered to cre= ate > > > > > > CONFIG_OF_PRIOR_STAGE is not a backdoor. And you are the DM maintaine= r. > > > > > > > some documentation for the design. Then I would have seen the probl= em > > > > immediately. > > > > > > > > Anyway, it is now covered by the above series. The use of devicetree > > > > in U-Boot is very clear, I think. > > > > > > I see neither a design by you nor a series that covers > > > CONFIG_OF_PRIOR_STAGE. I have suggested that if you really want to mo= ve > > > this blob to a devicetree you could apply an overlay tree including > > > U-Boot specific fields to the devicetree of the prior stage. Did you = yet > > > respond to this? > > > > Given that I feel like "u-boot,dm-spl" and "u-boot,dm-pre-reloc" are > > unlikely to survive upstream review, I would like to hear what you think > > about applying overlays, at least in general, Simon. >=20 > I would be pretty disappointed if vendor,propname could not survive > upstream review, given that it is in the DT spec explicitly, and that > linux, is used in Linux. >=20 > To answer your question, I think it is a terrible idea and would lead > to much pain and misery and eventually the failure of U-Boot to > function as a useful and efficient bootloader . It moves something > that I think can be easily accomplished (from a technical POV anyway) > at built-time into the run-time domain. Leaving aside that devicetree > overlays are arguably not supported/implemented so far as the DT spec > is concerned, it adds overhead to SPL and U-Boot (particularly > pre-reloc) that is likely to make the whole thing infeasible. Perhaps for u-boot,dm-pre-reloc and dm-spl we can figure out something slightly clever? I really had hoped that by now we might know enough about what really is or isn't needed that early that we could rule-of-thumb our way out of it or something. > Also, somewhat off-topic, this is the first I have ever heard of the > idea of U-Boot needing to put its properties in a separate place. I > tried to cover this in 'Why not have two devicetrees?' here: >=20 > https://patchwork.ozlabs.org/project/uboot/patch/20210828164630.81050-4-s= jg@chromium.org/ >=20 > How hard do we really want to make this? If a DT is provided to > U-Boot, it needs to be suitable for U-Boot. >=20 > The whole idea is driven from a misconception that U-Boot is just > borrowing a devicetree from Linux or qemu or TF-A. >=20 > So to the extent that this implies that U-Boot cannot have its own > properties and nodes in the devicetree; If we need properties to exist in the device tree that we're provided then it needs to be in the upstream device tree and bindings. Is u-boot,dm-spl valid and in a registered namespace? Yes. But if we expect to be able to play nicely with the whole of the device tree ecosystem then we need to document what we're doing, in the upstream binding documentation so that validators can validate it. If we expect to be given and then pass on our device tree there's not another option here. Otherwise then yes, we are just borrowing a device tree from someplace else and making it one-off. That this hasn't come up before is at least partly because it's only getting closer to the point where it seems like just maybe the OS has sufficiently complete bindings that the thought of updating the device tree infrequently is becoming feasible. > No. >=20 > No. >=20 > No. >=20 > U-Boot uses the devicetree for its configuration and it must be > supplied based on U-Boot's requirements. I will try to send another > version of the devicetree doc series. Maybe we'll need to have a higher level re-think then too, at least looking forward, about what can and can't live where. --=20 Tom --62ujixhRsxbgxlYW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmE6ckQACgkQFHw5/5Y0 tyx7/QwAicY2dNFcHNiHp6m5UVFzPVlAPVmLDS5gCKPLYj5ADy+/8n/Mykl6wWCK VYnzdBm/pDZhPiKG3KRsdYxAdDsj5DZDmFFDaMdlFOdvrkPMV1vRvESuiMc3yGRJ dLwBknDVT4giRihUNV1qDr/VnbXFICyrhuGokdN7fCBvvADk0MvO37j3ZySknWfg 7fD+WDMsB+uOMfAxaby58pT9k7iuJQmYe9u+/n5DC7q2y+qo5/zscqwPLIGKkCv4 9GI0hpUId2vpiav1QOpEUt1vwM6eMlg6kxsnIp/9qyXB2LKRmGKbb3GEywxA1Lvl pa8YkoRXVS3UCNoHYNZMRJ+9I//OiHsf1vB/8+1klZCOWVmB7PK0kYfB8PG/KTBQ mTtarBsDWcfbH0gytyNtOc/lMjMAJPggXFnHRMWMXaZ/P1aKjRjabkhFygG6q08K 1uVmmKQ3D/YfPTqcA3rMHijRBdC4RRdDaedY1/HbiwjO2uGUTY68H/AC66e8MUTj fH+sIMp0 =wZeE -----END PGP SIGNATURE----- --62ujixhRsxbgxlYW--