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

[Harsh Prateek Bora <harshpb@linux.ibm.com>]

On 10/29/25 16:09, BALATON Zoltan wrote:
> On Wed, 29 Oct 2025, Harsh Prateek Bora wrote:
>> On 10/29/25 15:28, BALATON Zoltan wrote:
>>> On Wed, 29 Oct 2025, 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 Harsh,
>>>
>>> You should be able to download mbox from
>>> https://patchew.org/QEMU/20251028151923.10DBB5972E5@zero.eik.bme.hu/
>>> and git am that. This was tested by somebody else and worked.
>>
>> Yes, git fetch from there seems to work, thanks.
>>
>> If needed
>>> I could try to split the binary into another patch or send you the 
>>> patch again. Maybe lore does not store large files?
>>
>> Having only binary file update into its own separate patch may be better
>> as a best practice, so other patch gets non-binary changes for easy 
>> review.
>> Also, maintaining the date stamp may also be helpful in some cases.
>> Let me know if you think otherwise.
> 
> Which date stamp maintaining are you referring to? I can split the patch 
> in two later today or tomorrow if you want and send a v2 but not right 
> now. For that to compile and work after each patch it would need to add 
> the new binary in one patch then remove the old one after changing its 
> usage. Or maybe even 3 patches: first updating submodule, then adding 
> binary rebuilt from that then changing usage and removing old one. I 
> think this would make the series larger as git now seems to contain 
> binary diff between old and new versions but if these are in different 
> patch it may still add the removed binary as a binary patch. So this 
> only works if the old and new binary is the same name or renamed in one 
> patch but then that would break if the usage is not updated in the same 
> patch. So maybe patch one to update submodule, patch 2 to add binary 
> with old name and patch 3 to rename the binary could work but does that 
> worth the hassle and any better than this single patch?


I was referring to the version number in binary name as date stamp which
is being removed, but that's fine. I think we can take this patch as-is
for now as split doesn't add much value and also we are close to freeze.

regards,
Harsh

> 
> Regards,
> BALATON Zoltan