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 E38D8C433F5 for ; Thu, 9 Sep 2021 12:08:20 +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 3D0516113E for ; Thu, 9 Sep 2021 12:08:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3D0516113E 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 0484383368; Thu, 9 Sep 2021 14:08:17 +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="t9zyAMYp"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 03C478338C; Thu, 9 Sep 2021 14:08:16 +0200 (CEST) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 BFBF583365 for ; Thu, 9 Sep 2021 14:08:11 +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-qv1-xf29.google.com with SMTP id a12so950484qvz.4 for ; Thu, 09 Sep 2021 05:08:11 -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=ee8wHJVsmytf2LSjHMdPmJ9yPGKVhM7YMrwQiDgiXAU=; b=t9zyAMYpcoB0yp0VGJ3IOzhULex9YJXAzZrwlmohh6e/3YntBL+6DvYZfdVAkjGcee z2vfuZ9/H0ILCBhuvCdDI3l17nbtP67Ys525QyUrweE135lwpNVQvWzZ988l0quRRoNC GCoPI5kvXlxhoyZhR8Nkhhx7mx79oR7ixAD2c= 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=ee8wHJVsmytf2LSjHMdPmJ9yPGKVhM7YMrwQiDgiXAU=; b=2wlqc6GSQTTDeSNWYOhIfAAqZgfuiiCiQPqBZ23jveJcr/DZJ7lkbGEEQ7TH5OYwH4 bXKajqwCqUZx+IX/hD8KWQEGYpDdPF1e7trDpe2kdVN90x8Qu2La9vQJGEYldC5HE9kD /Y9G9g7c+tNLKVAV0g/2Vza1JHK7yr9MatSqjI9CNrMG9is1L1xYEQXvGoQLat1xZgcZ Vbmvr3vxXHrTJIzrN2emb1PErlXW+N5NLIOKAHPLaMe9qqkTaXHWD4KMEM2lSEGMOGEe HoC2mu/qVlHF08cIpoiWUysIzSXZfJAsZ4mWqZ1OngTdEN0GaEL/KkL8TNfVb8vcAcBd usRw== X-Gm-Message-State: AOAM533EWc7gcNwGznAEjXrthxitlUAetbksRNjREUpTUgNoApaOsZLC qj3RDunqfw/4/RvAvL4UtJFHeg== X-Google-Smtp-Source: ABdhPJyXpXDdmM8NYfM/r5j2+W0ebSfXfTafpO6mga5qxuZkUKz27/FHV+vpyQkWyxU0h4TQgS0ZMA== X-Received: by 2002:a0c:e883:: with SMTP id b3mr2364087qvo.16.1631189290588; Thu, 09 Sep 2021 05:08:10 -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 j3sm1156780qki.104.2021.09.09.05.08.09 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 Sep 2021 05:08:10 -0700 (PDT) Date: Thu, 9 Sep 2021 08:08:08 -0400 From: Tom Rini To: Heinrich Schuchardt Cc: Simon Glass , U-Boot Mailing List , Alexander Graf , Masahisa Kojima , Ilias Apalodimas , AKASHI Takahiro Subject: Re: Pull request for efi-2021-10-rc4 Message-ID: <20210909120808.GY12964@bill-the-cat> References: <61e2e1cc-b474-84dd-eceb-bb86a59972be@gmx.de> <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FvI60RJo/OoThODE" Content-Disposition: inline In-Reply-To: <146342ea-08a3-ec4a-535c-5bcecd54675a@gmx.de> 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 --FvI60RJo/OoThODE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 09, 2021 at 12:52:52PM +0200, Heinrich Schuchardt wrote: >=20 >=20 > On 9/9/21 10:56 AM, Simon Glass wrote: > > Hi Heinrich, > >=20 > > On Sat, 4 Sept 2021 at 12:08, Heinrich Schuchardt = wrote: > > >=20 > > >=20 > > >=20 > > > Am 4. September 2021 19:39:49 MESZ schrieb Tom Rini : > > > > On Sat, Sep 04, 2021 at 07:03:48PM +0200, Heinrich Schuchardt wrote: > > > > >=20 > > > > >=20 > > > > > Am 4. September 2021 16:37:22 MESZ schrieb Tom Rini : > > > > > > On Sat, Sep 04, 2021 at 03:08:38PM +0200, Heinrich Schuchardt w= rote: > > > > > > >=20 > > > > > > >=20 > > > > > > > Am 4. September 2021 15:01:11 MESZ schrieb Tom Rini : > > > > > > > > On Sat, Sep 04, 2021 at 11:56:47AM +0200, Heinrich Schuchar= dt wrote: > > > > > > > >=20 > > > > > > > > > Dear Tom, > > > > > > > > >=20 > > > > > > > > > The following changes since commit 94509b79b13e69c209199a= f0757afbde8d2ebd6d: > > > > > > > > >=20 > > > > > > > > > btrfs: Use default subvolume as filesystem root (2021-= 09-01 10:11:24 > > > > > > > > > -0400) > > > > > > > > >=20 > > > > > > > > > are available in the Git repository at: > > > > > > > > >=20 > > > > > > > > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > > > > > > > > > tags/efi-2021-10-rc4 > > > > > > > > >=20 > > > > > > > > > for you to fetch changes up to 1dfa494610c5469cc28cf1f853= 8abf4be6c00324: > > > > > > > > >=20 > > > > > > > > > efi_loader: fix efi_tcg2_hash_log_extend_event() param= eter check > > > > > > > > > (2021-09-04 09:15:09 +0200) > > > > > > > > >=20 > > > > > > > > > ---------------------------------------------------------= ------- > > > > > > > > > Pull request for efi-2021-10-rc4 > > > > > > > > >=20 > > > > > > > > > Documentation: > > > > > > > > >=20 > > > > > > > > > Remove invalid reference to configuration variable i= n UEFI doc > > > > > > > > >=20 > > > > > > > > > UEFI: > > > > > > > > >=20 > > > > > > > > > Parameter checks for the EFI_TCG2_PROTOCOL > > > > > > > > > Improve support of preseeding UEFI variables. > > > > > > > > > Correct the calculation of the size of loaded images. > > > > > > > > > Allow for UEFI images with zero VirtualSize > > > > > > > > >=20 > > > > > > > > > ---------------------------------------------------------= ------- > > > > > > > > > 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, Deplo= yedMode > > > > > > > > > efi_loader: correct determination of secure boot s= tate > > > > > > > > >=20 > > > > > > > > > Masahisa Kojima (3): > > > > > > > > > efi_loader: add missing parameter check for EFI_TC= G2_PROTOCOL api > > > > > > > > > efi_loader: fix boot_service_capability_min calcul= ation > > > > > > > > > efi_loader: fix efi_tcg2_hash_log_extend_event() p= arameter check > > > > > > > >=20 > > > > > > > > And I don't see Simon's revert in here either. And he aske= d you about > > > > > > > > that yesterday: > > > > > > > > https://lore.kernel.org/r/CAPnjgZ3eRdjF0jb9S-cJK6y+feuyRyWf= 0hNkf2triB4DR4UFBQ@mail.gmail.com/ > > > > > > > >=20 > > > > > > > > So at this point, are you asserting there is nothing to rev= ert? > > > > > > >=20 > > > > > > > Never. Simons "revert" is breaking functionality. The concept= for suporting blobs in devicetrees supplied by a prior bootstage has not b= een defined yet. > > > > > >=20 > > > > > > And to be clearer, reverting something that was introduced in o= ne 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. External= projects > > > > > > may not depend on some feature introduced at -rcN unless they'r= e willing > > > > > > to accept that some changes could happen before release. > > > > > >=20 > > > > >=20 > > > > > There is no value delivered by Simon's series. Neither does the i= mage get smaller nor does it fix anything. If he wants to enforce a design,= it must work for all use cases. But this requires some conceptual work. > > > >=20 > > > > Yes, and what's the rush to not do the conceptual work? If I recall > > > > part of the thread correctly, yes, Simon didn't get his objections = in > > > > before the patches were merged, but it was early enough in the rele= ase > > > > cycle that taking a step back and reverting was a reasonable reques= t. > > > > What he had said wouldn't have changed if he had gotten the email o= ut a > > > > few days earlier. > > > >=20 > > > > So yes, please merge Simon's revert, or post and merge new more min= imal > > > > 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 related= 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. > > > >=20 > > >=20 > > >=20 > > > There is nothing wrong with the current code. > >=20 > > The current code is misconceived and I did go to great effort to > > explain that in the 'devicetree' series. > >=20 > > >=20 > > > It is Simon's concept of blobs in devicetrees that is borked in that = it ignores QEMU and any board that gets the DT from a prior boot stage. > >=20 > > That's because I was completely unaware of this strange back-door > > approach. It would have helped a lot if someone had bothered to create >=20 > CONFIG_OF_PRIOR_STAGE is not a backdoor. And you are the DM maintainer. >=20 > > some documentation for the design. Then I would have seen the problem > > immediately. > >=20 > > Anyway, it is now covered by the above series. The use of devicetree > > in U-Boot is very clear, I think. >=20 > 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 move > 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. > > > Simon's patches have no functional end. So what do you mean by "same = functional end"? > >=20 > > So, please, again, will someone apply the revert before the release > > and people start relying on it. >=20 > Sure we want capsule updates. My understanding is that you want to > modify the current implementation. That is fine. It has no effect on the > user where a blob is stored unless you remove it as your series does. So > I cannot understand your urgency. Instead collaborate with Ilias and me > on the possible design change. I believe Simon's urgency comes from the idea that once we put this method in a release we'll be stuck with using it or supporting it forever. That's certainly a general concern of mine. We can make changes between -rc1 and release and if something else decides to depend on an ABI we changed in the middle there, that was a bad idea on their part. But then it's on us once it's in a full release. --=20 Tom --FvI60RJo/OoThODE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmE5+ScACgkQFHw5/5Y0 tyxbTQv+IgEgt9II4ahkBV2LoZ8uFjcG0ViI/Rh/ez0WjL9kJnbYQim8cpi5KreO o2MWGuetQwZli+UsTKq2d30hMa9Wa6FziGUG9LAeOiDkSZXVzbzqsJYFpYGnf0hd Ec408HIsJ3r2iIGA8ex3OHgVwpebgpXAya+OCZ0r2OlO00D2JDV2eBVC48tC7wT3 xM/s/m95lbIqPQ7ULFXRG8ld1XG/gRdLxCvyaomyMMVRhMjc2CkGPPNDYQIiMSBC 0Ezw4ZitKF+IRWzAZ/vdlyZJI2P6TPG+MUZU/3l8LT8itgnxIdxrKciYnHLRw/8Q VZwDJEFAQ4VtfHxkMJvrTxV9NcMEdBKsS4hUPFRZ+TORZRT2trr2OmjoTILIBAjK ZMxpWCVqw4Zpkt3KwrAJncyuYgQTKWM1LP5d27PNsdZsFiBMoTswTeTdtMcQSySu ttr1XHN+UrD2FMhZT6p51nin8Xx59jVdoNIXxwat809EC6Ed1lDw0m6P8TyaubyK fTjZKakX =Yn3O -----END PGP SIGNATURE----- --FvI60RJo/OoThODE--