[PATCH v6] Improve handoff prepare on SoCFPGA

[Sune Brian]

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!!!
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
>
> Regards,
> Simon