[PATCH v6] Improve handoff prepare on SoCFPGA

[Sune Brian]

On Thu, Apr 30, 2026 at 12:28 PM Chee, Tien Fong
<tien.fong.chee at altera.com> wrote:
>
> 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 at chromium.org> wrote:
> >> Hi Sune,
> >>
> >> On Wed, 29 Apr 2026 at 08:34, Sune Brian <briansune at gmail.com> wrote:
> >>> On Wed, Apr 29, 2026 at 10:21 PM Simon Glass <sjg at chromium.org> wrote:
> >>>> Hi Brian,
> >>>>
> >>>> On Tue, 28 Apr 2026 at 08:34, Sune Brian <briansune at gmail.com> wrote:
> >>>>> On Tue, Apr 28, 2026 at 10:04 PM Simon Glass <sjg at chromium.org> wrote:
> >>>>>> Hi Brian,
> >>>>>>
> >>>>>> On 2026-04-23T04:28:24, Sune Brian <briansune at 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.

Hi T.F.,

Drop this, I don't care.

Thanks,
Brian

>
> Best regards,
>
> Tien Fong
>