[PATCH v4] Improve handoff prepare on SoCFPGA
Sune Brian
briansune at gmail.com
Thu Apr 23 00:29:46 CEST 2026
On Thu, Apr 23, 2026 at 6:10 AM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Brian,
>
> On Wed, 22 Apr 2026 at 15:13, Sune Brian <briansune at gmail.com> wrote:
> >
> > On Wed, Apr 22, 2026 at 10:54 AM Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi Brian,
> > >
> > > On 2026-04-21T00:47:19, Sune Brian <briansune at gmail.com> wrote:
> > > > Improve handoff prepare on SoCFPGA
> > > >
> > > > There are some cases that the Python scripts
> > > > are run and the qts files are not replaced.
> > > >
> > > > This patch introduces:
> > > > 1) TMP folder for Python script
> > > > 2) TMP folder will automatically remove on exit
> > > > 3) If PY script fails, the replace will not conduct.
> > > > 4) Only when PY script passed the replace with keep
> > > > or without keep will be done via NEW HANDOFF_KEEP=xxx
> > > > 5) When keep is selected the old files are renamed to
> > > > xxx.h.handoff.<timestamp>
> > > >
> > > > As such this ensure qts folder h files are properly
> > > > updated.
> > > >
> > > > Signed-off-by: Brian Sune <briansune at gmail.com>
> > > >
> > > > arch/arm/mach-socfpga/config.mk | 27 ++++++++++++++++++++++++---
> > > > 1 file changed, 24 insertions(+), 3 deletions(-)
> > >
> > > Reviewed-by: Simon Glass <sjg at chromium.org>
> > >
> > > Some thoughts though.
> > >
> >
> > Hi Simon.
> >
> > > We try to add a change log for each revision and use imperative
> > > present tense (Introduce a temp folder... rather than This patch
> > > introduces...). Spell out Python script rather than PY script, and
> > > reword as prose or a bullet list instead of 1), 2), ... You could also
> > > explain *why* the qts files were sometimes not being replaced - the
> >
> > Because it is not fully traceable, git pull sometimes could introduce
> > some kind of unknown cases that even run make prepare will not update
> > the h files or the python script itself does not fully replace it from
> > first place.
> > So the easiest way to play safe in any possible condition is
> > [remove and replace] or simply [rename and create].
> >
> > And I don't even fully confirm the cases, while this patch does improve
> > the previous .mk operation no matter if it is solving the unreplacing issue
> > or not.
> >
> > So the motivation was explained from the title itself.
> >
> > > motivation paragraph currently just says some cases without saying
> > > what goes wrong.
> > >
> > > The message says kept files are renamed to xxx.h.handoff.<timestamp>
> > > but the code uses .h.handoff_backup.<timestamp> - they should match.
> >
> > That my mistake on the description, indeed it should be
> > .h.handoff_backup.<timestamp>
> >
> > The idea just follows T.F. previous optional idea so I don't fully pay attention
> > to the wordings.
> >
> > >
> > > > diff --git a/arch/arm/mach-socfpga/config.mk b/arch/arm/mach-socfpga/config.mk
> > > > @@ -43,6 +43,27 @@ socfpga_g5_handoff_prepare:
> > > > + if [ -n '$${HANDOFF_KEEP+x}' ] && [ '$${HANDOFF_KEEP:-1}' != '0' ]; then \
> > >
> > > How about:
> > >
> >
> > No I don't like this because you ignored my original idea on:
> > 1) HANDOFF_KEEP= should run keep
> > because HANDOFF_KEEP cannot without = in .mk usage
> > 2) When users use this flag, hence, it is telling that they want to
> > keep the thingy.
> > So it makes no sense to =1 or =0 to further control it from first place.
> > This flag is inherently boolean logic.
> > But due to your suggestion I further elaborated this boolean flag to
> > support =0 or =1 or =x cases.
> >
> > Sorry for this part, I will not change.
>
> That's fine...note that you have my review tag, so you can add that to
> a new version, if you do one.
>
> >
> > Cheers,
> > Brian
> >
> > > if [ '$${HANDOFF_KEEP:-0}' != '0' ] ; then \
Hi Simon,
V5 has been released.
Due to T.F. "please to use your check condition"
Logically speaking.
The check condition now has become:
A person has no intention to use the restroom.
But that person intentionally walk in front of the restroom door and
speak out not going to use the restroom,
Then that person simply goes back to where he came from and does
not even enter the restroom.
What a wonderful world =]
Enjoy,
Brian
> Regards,
> Simon
More information about the U-Boot
mailing list