Re: [PATCH v6] Improve handoff prepare on SoCFPGA

["Chee, Tien Fong" <tien.fong.chee@altera.com>]

Hi Brian,


On 30/4/2026 1:14 am, Simon Glass wrote:
> [CAUTION: This email is from outside your organization. Unless you trust the sender, do not click on links or open attachments as it may be a fraudulent email attempting to steal your information and/or compromise your computer.]
>
> On Thu, 30 Apr 2026 at 02:44, Simon Glass <sjg@chromium.org> wrote:
>> Hi Sune,
>>
>> On Wed, 29 Apr 2026 at 08:34, Sune Brian <briansune@gmail.com> wrote:
>>> On Wed, Apr 29, 2026 at 10:21 PM Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Brian,
>>>>
>>>> On Tue, 28 Apr 2026 at 08:34, Sune Brian <briansune@gmail.com> wrote:
>>>>> On Tue, Apr 28, 2026 at 10:04 PM Simon Glass <sjg@chromium.org> wrote:
>>>>>> Hi Brian,
>>>>>>
>>>>>> On 2026-04-23T04:28:24, Sune Brian <briansune@gmail.com> wrote:
>>>>>>> Improve handoff prepare on SoCFPGA
>>>>>>>
>>>>>>> Ensure qts folder header files are properly updated by isolating
>>>>>>> the Python execution environment. This prevents partial or failed
>>>>>>> script runs from corrupting the target directory.
>>>>>>>
>>>>>>> Changelog v5 -> v6:
>>>>>>>   - Clean HANDOFF_KEEP comments.
>>>>>>>
>>>>>>> Changelog v4 -> v5:
>>>>>>>   - Change HANDOFF_KEEP condition to if [ '$${HANDOFF_KEEP:-0}' != '0' ]
>>>>>>>   - Add HANDOFF_KEEP and HANDOFF_PATH comments in config.mk
>>>>>>>
>>>>>>> Changes:
>>>>>>>   - Implement a temp folder for Python script execution.
>>>>>>>   - Clean temp folder automatically despite execution failures.
>>>>>>>   - Gate the file replacement process on the successful exit of
>>>>>>>     the Python scripts.
>>>>>>>   - Execute the replacement (with or without keep) only upon script
>>>>>>>     success via the NEW HANDOFF_KEEP=xxx variable.
>>>>>>> [...]
>>>>>>>
>>>>>>> arch/arm/mach-socfpga/config.mk | 39 ++++++++++++++++++++++++++++++++++++---
>>>>>>>   1 file changed, 36 insertions(+), 3 deletions(-)
>>>>>
>>>>> Dear Simon,
>>>>>
>>>>> B.C. the server is down and I don't expect Google to have an auto fail
>>>>> mailing recovery.
>>>>>
>>>>>> I see 6 copies of this v6 patch in patchwork, so I wonder if I got the
>>>>>> right one?
>>>>> I will try to respond to this email as politely as possible.
>>>>> Please reference from "patchwork.ozlabs.org" list.
>>>>>
>>>>>> The per-version changelogs belong below the '---' separator, not in
>>>>>> the commit body. Also U-Boot convention is 'Changes in vN:' rather
>>>>>> than 'Changelog vN -> vN+1:'.
>>>>>>
>>>>>> You could try using 'patman' which will get this right for you automatically:
>>>>>>
>>>>>> https://docs.u-boot.org/en/latest/develop/patman.html
>>>>>>
>>>>> 1) I only do basic software
>>>>> 2) I used ./script/checkpatch.pl There are no errors, warnings etc.
>>>>> 3) There is nothing to do with the patch itself either the software
>>>>> nor the file itself.
>>>>> 4) I am not too familiar with patman
>>>>> 5) There are many better things to do rather than complaining about
>>>>> the patch headers.
>>>>>
>>>>> So forgive me I really don't give a damn on whatever the header requirements.
>>>>> If you feel this is not passing the patch standard simply reject or
>>>>> label all patches to
>>>>> "Changes Requested".
>>>> That's up to whoever applies this patch. I am just a reviewer :-)
>>> Hi Simon,
>>>
>>> I am going to ignore all your mail in the future.
>>> So review whatever you like, don't care.
>>> There are many patch not following whatever rules or guidelines you
>>> mentioned.
>>> Just review those as well. What a waste of time on your emails.
>>>
>>> As politely as possible!!!
>> Oh, sorry about that and also the server being down, etc.. The
>> maintainer for SoCFPGA will handle applying this in any case.
>>
>>> Brian
>>>
>>>> The reason for the formatting rules is mostly so that maintainers can
>>>> apply them without manually redoing the patch, etc.
>>>>
>>>> There is also this which might help (although you might not want more reading):
>>>>
>>>> https://docs.u-boot.org/en/latest/develop/sending_patches.html#commit-message-conventions


I have reviewed this patch.


While the functional change appears reasonable, the patch cannot be
applied in its current form because the commit message and version
history do not follow U-Boot patch submission conventions. Specifically:

- Per-version change history must be placed below the '---' separator.
- The required format is 'Changes in vN:'. Custom formats such as
   'Changelog vN -> vN+1:' are not acceptable.

Maintainers rely on these conventions so patches can be applied directly
using git am without manual rework. I will not correct the commit history
on behalf of the contributor.

Please resend the patch with the commit message formatted correctly.
Further review or application will only proceed once this requirement is
met.

Best regards,

Tien Fong