Applying patches to mainline (Was: Re: [PATCH v2 0/7] efi_loader: Add support for logging to a buffer)

[Tom Rini]

On Thu, Dec 12, 2024 at 07:04:54AM -0700, Simon Glass wrote:
> Hi Ilias,
> 
> On Sat, 7 Dec 2024 at 01:18, Ilias Apalodimas
[snip]
> > Another example is the fdt sutff here
> > https://lore.kernel.org/u-boot/20241201144240.1664398-5-sjg@chromium.org/
> > Tom, Raymond and I spent a lot of our time explaining why we need this
> > feature like this and what's the technical reason behind the decision.
> > Your commit message basically says "I know better and you should all
> > listen to my almighty ideas and btw this breaks 3 special ancient
> > platforms, so I am reverting this".
> 
> This is a deflection at best. WIth OF_BLOBLIST, you can just enable
> that option and get what you want. You can even make it the default in
> U-Boot. The issue is that you don't want to have the option. But
> without the ability to turn the option off, my special, ancient
> platforms, that no one cares about except me, break.
> 
> > Now I don't know who Kevin and BoB
> > are and I wish them luck, but that's hardly a readable commit message
> > or will mean anything in a year from now.
> 
> chromebook_kevin and chromebook_bob are a rk3399-based Chromebooks
> 
> Again, the commit message is not a core issue. If you found yourself
> in a reflective mood, you might want to consider how I feel about 5-6
> platforms which I care about a lot, being permanently broken in Tom's
> tree.

Having just this morning figured out the problem with those chromebooks
(because they're available in CI, so thank you for that work), I think
this is also a good example of one of the problems. My recollection of
the threads from last year does not include you mentioning that on these
three platforms the issue is that you put the fixed bloblist address in
DRAM *and* that SPL initializes DRAM here (not TPL, not TF-A) that's the
concern. My recollection of the threads is you had very different
technical reasons for wanting what you proposed and those technical
reasons had technical objections. I've posted
https://patchwork.ozlabs.org/project/uboot/list/?series=436459&state=*
now and that fixes those three platforms. And we could have done that a
year ago if you had explained the problem on those platforms. I would
have asked why not putting the bloblist in IRAM instead, at that point,
and you may have had an answer, but that would have still left coral to
sort out.

And how is this part of the problem? You cannot suggest architectural
designs without explaining the technical details of what and why you
want something. We all spent countless hours arguing about some feature
of bloblist design which zero platforms actually need.

> > The way I read this commit message is that you show zero respect for
> > the effort all of the other people put into code explaining and
> > documenting the feature, your 'justification' has no technical
> > background whatsoever and then you come back complaining that people
> > don't appreciate your efforts.
> 
> Obviously you are entitled to your opinions, but I don't agree, sorry.
> I doubt anyone is particularly interested in my thoughts on this, so
> I'll refrain from commenting further.
> 
> Just to confirm, nothing in your email appears to address any of my
> concerns. If it was intended to, please point out what I missed.

No, this is another example of the problems. You've been given feedback
here, which is that your communication skills are a problem, and your
response is to say you don't agree.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241212/977aa5f4/attachment.sig>