Re: [PATCH] hw/ppc/sam460ex: Update u-boot-sam460ex

[Cornelia Huck <cohuck@redhat.com>]

On Wed, Oct 29 2025, Thomas Huth <thuth@redhat.com> 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 20251028151923.10DBB5972E5@zero.eik.bme.hu
>> 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/20251027074404.25758-1-thuth@redhat.com/
>> 
>> 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?