On Wed, Oct 29 2025, Thomas Huth <[email protected]> wrote: > On 29/10/2025 07.31, Harsh Prateek Bora wrote: >> + Thomas >> >> Hi BALATON, >> >> I am unable to fetch it with b4 am, and I do not see it appear on lore also, >> not sure if its due to the binary size. >> >> harshpb:patches$ b4 am [email protected] >> Looking up https://lore.kernel.org/ >> r/20251028151923.10DBB5972E5%40zero.eik.bme.hu >> Grabbing thread from lore.kernel.org/ >> all/20251028151923.10DBB5972E5%40zero.eik.bme.hu/t.mbox.gz >> Server returned an error: 404 >> harshpb:patches$ >> >> I guess you may need to send a PULL SUBSYSTEM req like Thomas did for slof: >> https://lore.kernel.org/qemu-devel/[email protected]/ >> >> Hi Thomas, >> Is it a known thing to deal with binary updates ? > > Hi, > > honestly, I can't remember clearly why we introduced these subsystem pull > requests in the past ... Maybe it was related to some problems with binary > patches, but I think it was rather meant as a staged approach for the case > where the maintainer of the firmware is not the main maintainer of the > architecture subsystem, so that the main maintainer gets another chance of > doing tests before the final pull request to the master branch. > > Conny, Alexey, do you remember?
Hmm... I thought subsystem pull reqs were mainly intended for the case where there might be different maintainers, or one person handling a subsys for that release. However, I'm not sure if I ever actually b4 am'ed a binary update (for s390, I think I usually regenerated the binary myself, and it would get merge via a pull from whoever was handling the main branch.) Regardless, I think it's easiest to put a binary update into its own separate patch?
