Hi Tom, On Sat, 4 Jan 2025 at 03:26, Tom Rini <[email protected]> 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 <[email protected]> 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] [email protected]: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-fb8...@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=*
