[PATCH v6] Improve handoff prepare on SoCFPGA

[Sune Brian]

On Thu, Apr 30, 2026 at 12:32 PM Sune Brian <briansune at gmail.com> wrote:
>
> 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
> >

Dear Tom,

Sorry for the trouble.
Please reject this patch series.

Thanks,
Brian