Hi Tom, On Wed, 28 May 2025 at 15:12, Tom Rini <[email protected]> wrote: > > On Wed, May 28, 2025 at 08:35:37AM +0100, Simon Glass wrote: > > Hi Ilias, > > > > On Tue, 27 May 2025 at 10:20, Ilias Apalodimas > > <[email protected]> wrote: > > > > > > Hi Simon, > > > > > > On Tue, 27 May 2025 at 11:20, Simon Glass <[email protected]> wrote: > > > > > > > > Hi Ilias, > > > > > > > > On Sat, 24 May 2025 at 19:13, Ilias Apalodimas > > > > <[email protected]> wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Sat, 24 May 2025 at 15:09, Simon Glass <[email protected]> wrote: > > > > > > > > > > > > A previously rejected patch to move the EFI public cerificate out > > > > > > of the > > > > > > devicetree has recently been applied. This series reverts the > > > > > > change, > > > > > > pending further discussion as to why it was accepted. > > > > > > > > > > I spent a good amount of time, writing the commit message an > > > > > explaining why this patch was sent > > > > > > > > Yes, that is [1] and I did read it carefully before sending my series. > > > > > > > > From my POV there are two things wrong there: > > > > - The signature is not an internal U-Boot ABI. > > > > > > It is, as it is for every firmware that builds out there. EDKII does > > > the same thing. > > > > I mean that in U-Boot's case it is a published and documented > > interface, or was until a few weeks ago. > > > > > > > > > It is how U-Boot works, > > > > so if a build systems wants to inject a key it should use that > > > > mechanism, not add a new mechanism into U-Boot's build system. If it > > > > would help to have some documentation somewhere which says this, I > > > > would be happy to send a patch to add something > > > > - QEMU is blocked from accepting devicetree additions due to another > > > > Linaro employee's refusal to accept a patch[2] > > > > > > It's not blocked. It has been NAK'ed and IMHO for a very good reason. > > > > > > > > > > > > (which btw wasn't 'rejected', you > > > > > forcefully reverted it back then with no agreements from anyone) > > > > > > > > The original series [4] was applied (I believe accidentally) against > > > > my objections. Heinrich pulled the revert [5]. I went ahead and did > > > > the QEMU patch, to help with your issue*. > > > > > > Heinrich applied the patches initially, and you send the revert, that > > > none of the patch reviewers ack'ed. > > > You reasoning back then is that the RO functionality was moot, because > > > we didn't have it. It's here now. > > > > That was one aspect of my reasoning, but of course we can copy the > > signature into protected memory, make the devicetree readonly, etc. if > > desired. > > > > > > > > > > > > > > and > > > > > why we prefer to do it this way. tl;dr early boot loaders that pass as > > > > > a DT is a problem now. > > > > > If there's a good reason to revert it, please explain it on the > > > > > commit message > > > > > > > > The reasoning hasn't changed from the discussion three years ago - > > > > please see [4]. There's also lots of discussion on your original > > > > series and my revert, e.g the cover letter. A highly relevant part of > > > > this is that devicetree is where config should be stored, so the build > > > > system has control over what is placed there. > > > > > > > > But in any case, it isn't right to send the series again, under a > > > > different name, e.g. not mentioning device tree. > > > > > > > > [..] > > > > > > > > Regards, > > > > Simon > > > > > > > > * The QEMU patch is still outstanding after three years. Could you > > > > please talk to Peter Maydell and see if you can get this resolved? I > > > > have sent it twice since, most recently in April [7] but there was not > > > > even a reply. > > > > > > Because they NAK'ed it a few years ago, and aren't willing to take it. > > > I don't think there's anything to discuss and for the record I agree > > > with the QEMU maintainers on this. > > > > Yes, I agree that discussion is unlikely to be fruitful. My point > > remains though that your series should not have been applied, given > > the previous discussion. > > > > This thread and the links should provide context for the future, if needed. > > > > One other thing I forgot for the record is that [8] and [9] are only > > needed due to Linaro's refusal to accept the QEMU patch or propose a > > convenient alternative. > > > > For now I've applied this series to my tree. > > You can do whatever you like in your downstream tree, but please stop > implying that "Linaro" is in charge of QEMU. They very much are not and > I don't want other communities to think that you and your attitude > represent the U-Boot project.
That wasn't my intention at all. Where are you reading that? I am just pointing out that Linaro rejected [2]. Ilias (also at Linaro) has stated that he agreed with the decision. Do you agree with my analysis here? Regards, Simon > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/ > > > > [2] > > > > https://patchwork.kernel.org/project/qemu-devel/patch/[email protected]/#24481799 > > > > [3] > > > > https://lore.kernel.org/u-boot/CAPnjgZ2uM=n8Qo-a=DUkx5VW5Bzp5Xy8=wgmrw8esqubk00...@mail.gmail.com/ > > > > [4] > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=253693&state=*&archive=both > > > > [5] > > > > https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/ > > > > [6] > > > > https://patchwork.kernel.org/project/qemu-devel/patch/[email protected]/ > > > > [7] > > > > https://patchwork.kernel.org/project/qemu-devel/patch/[email protected]/ > > [8] > > https://lore.kernel.org/u-boot/[email protected]/ > > [9] https://docs.u-boot.org/en/latest/develop/devicetree/dt_qemu.html > > -- > Tom
