Hi Heinrich, On Sat, 4 Sept 2021 at 12:08, Heinrich Schuchardt <[email protected]> wrote: > > > > Am 4. September 2021 19:39:49 MESZ schrieb Tom Rini <[email protected]>: > >On Sat, Sep 04, 2021 at 07:03:48PM +0200, Heinrich Schuchardt wrote: > >> > >> > >> Am 4. September 2021 16:37:22 MESZ schrieb Tom Rini <[email protected]>: > >> >On Sat, Sep 04, 2021 at 03:08:38PM +0200, Heinrich Schuchardt wrote: > >> >> > >> >> > >> >> Am 4. September 2021 15:01:11 MESZ schrieb Tom Rini > >> >> <[email protected]>: > >> >> >On Sat, Sep 04, 2021 at 11:56:47AM +0200, Heinrich Schuchardt wrote: > >> >> > > >> >> >> Dear Tom, > >> >> >> > >> >> >> The following changes since commit > >> >> >> 94509b79b13e69c209199af0757afbde8d2ebd6d: > >> >> >> > >> >> >> btrfs: Use default subvolume as filesystem root (2021-09-01 > >> >> >> 10:11:24 > >> >> >> -0400) > >> >> >> > >> >> >> are available in the Git repository at: > >> >> >> > >> >> >> https://source.denx.de/u-boot/custodians/u-boot-efi.git > >> >> >> tags/efi-2021-10-rc4 > >> >> >> > >> >> >> for you to fetch changes up to > >> >> >> 1dfa494610c5469cc28cf1f8538abf4be6c00324: > >> >> >> > >> >> >> efi_loader: fix efi_tcg2_hash_log_extend_event() parameter check > >> >> >> (2021-09-04 09:15:09 +0200) > >> >> >> > >> >> >> ---------------------------------------------------------------- > >> >> >> Pull request for efi-2021-10-rc4 > >> >> >> > >> >> >> Documentation: > >> >> >> > >> >> >> Remove invalid reference to configuration variable 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 images. > >> >> >> 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, DeployedMode > >> >> >> efi_loader: correct determination of secure boot state > >> >> >> > >> >> >> Masahisa Kojima (3): > >> >> >> efi_loader: add missing parameter check for EFI_TCG2_PROTOCOL > >> >> >> api > >> >> >> efi_loader: fix boot_service_capability_min calculation > >> >> >> 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+feuyrywf0hnkf2trib4dr4u...@mail.gmail.com/ > >> >> > > >> >> >So at this point, are you asserting there is nothing to revert? > >> >> > >> >> Never. Simons "revert" is breaking functionality. The concept for > >> >> suporting blobs in devicetrees supplied by a prior bootstage has not > >> >> 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. External projects > >> >may not depend on some feature introduced at -rcN unless they're willing > >> >to accept that some changes could happen before release. > >> > > >> > >> There is no value delivered by Simon's series. Neither does the image 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. > > > >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 release > >cycle that taking a step back and reverting was a reasonable request. > >What he had said wouldn't have changed if he had gotten the email 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 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. > > > > > 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 that 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 create some documentation for the design. Then I would have seen the problem immediately. Anyway, it is now covered by the above series. The use of devicetree in U-Boot is very clear, I think. > > Simon's patches have no functional end. So what do you mean by "same > functional end"? So, please, again, will someone apply the revert before the release and people start relying on it. Regards, Simon
