[PATCH 00/67] upl: Align with the updated spec
Simon Glass
sjg at chromium.org
Sat Jan 4 20:32:17 CET 2025
Hi Tom,
On Sat, 4 Jan 2025 at 03:26, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Jan 03, 2025 at 12:45:36PM +1300, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 3 Jan 2025 at 03:44, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Thu, Jan 02, 2025 at 11:08:46AM +1300, Simon Glass wrote:
> > >
> > > > The current UPL spec[1] has been tidied up and improved over the last
> > > > year, since U-Boot's original UPL support was written.
> > > >
> > > > This series addresses various issues, with a goal of having U-Boot boot
> > > > EDK2.
> > > >
> > > > There is still more work to do, but this series gets to the point (on
> > > > QEMU) where the ACPI tables are required. Further work will be needed to
> > > > relocate the tables out of the QEMU firmware-filesystem.
> > > >
> > > > [1] git at github.com:UniversalPayload/spec.git commit 3f1450d
> > >
> > > Since this is on top of your fork, and not mainline, and you aren't even
> > > noting that in your cover letter it's probably not worth the time of
> > > everyone you sent this to, to look at.
> >
> > It applies to -next except for the QEMU script which you rejected. I
> > can't do anything about that. So I think you may have the
> > wrong end of the stick here.
> >
> > The only thing I can think of is that the UPL series depends on
> > Raymond's bloblist patch [1]. But I was assuming that would be applied
> > at some point and I didn't want to resend someone else's patch. I
> > don't have it in the sjg tree either yet, as I was hoping he would
> > write a test. In fact I would very-much like people to write tests
> > (and docs if needed) without needing to be asked.
> >
> > Regards,
> > Simon
> >
> > [1] https://lore.kernel.org/u-boot/CAFLszTjSGqmk8yYYbXFEaFZWFhF8uhj_rNxZz7ship1-Fb8p3Q@mail.gmail.com/
>
> A 60 part series that includes changes to something that was rejected,
> and depends on a series from someone else that was changes requested,
> and is again, 60+ patches, is not at all helpful. Please stop doing
> this.
As I see it, my only alternatives were to:
a) resend Raymond's patch unchanged (with a note that it is merely for
convenience), or
b) not send it, knowing that his patch will likely be applied before this series
I chose b. The single, dependent patch is really not an issue, IMO.
I often send large series, e.g. [2]. Sometimes, as with UPL, there is
just an enormous amount of work to get through. I really don't like
combining patches just to reduce the patch count. But I can split of
the pre-req patches (about 30) so I'll do that for v2. Honestly, I was
just desperate to get some of the work sent out so it didn't die on
the vine.
BTW, please reconsider your objections to the qemu script. I think it
might make sense to convert it to Python at some point, but the
complexity of building images and running QEMU for different use cases
is such that a script makes a lot of sense.
Regards,
Simon
[2] https://patchwork.ozlabs.org/project/uboot/list/?series=364775&state=*
More information about the U-Boot
mailing list