[PATCH v3] generic: mips: support harts to boot from mips_warm_boot

[Jessica Clarke]

On 28 Aug 2025, at 07:20, Jessica Clarke <jrtc27 at jrtc27.com> wrote:
> On 28 Aug 2025, at 06:32, Anup Patel <anup at brainfault.org> wrote:
>> On Thu, Jul 24, 2025 at 2:10 AM Chao-ying Fu <icebergfu at gmail.com> wrote:
>>> 
>>> We program reset base for harts (other than hart 0) to boot at
>>> mips_warm_boot that jumps to _start_warm. This helps to skip some code
>>> sequence to speed up.
>>> 
>>> Signed-off-by: Chao-ying Fu <cfu at mips.com>
>>> ---
>>> platform/generic/mips/mips_warm_boot.S | 20 ++++++++++++++++++++
>>> platform/generic/mips/objects.mk       |  2 +-
>>> platform/generic/mips/p8700.c          |  5 +++++
>>> 3 files changed, 26 insertions(+), 1 deletion(-)
>>> create mode 100644 platform/generic/mips/mips_warm_boot.S
>>> 
>>> diff --git a/platform/generic/mips/mips_warm_boot.S b/platform/generic/mips/mips_warm_boot.S
>>> new file mode 100644
>>> index 0000000..25cdb83
>>> --- /dev/null
>>> +++ b/platform/generic/mips/mips_warm_boot.S
>>> @@ -0,0 +1,20 @@
>>> +/*
>>> + * SPDX-License-Identifier: BSD-2-Clause
>>> + *
>>> + * Copyright (c) 2025 MIPS
>>> + *
>>> + */
>>> +       .text
>>> +       .align  12
>>> +       .globl  mips_warm_boot
>>> +mips_warm_boot:
>>> +       j       _start_warm
>>> +       .align  2
>>> +nmi_vector:
>>> +       j       _start_warm
>>> +       .align  2
>>> +cacheerr_vector:
>>> +       j       _start_warm
>>> +       .align  2
>>> +debugexc_vector:
>>> +       j       _start_warm
>> 
>> nmi_vector, cacheerr_vector, and debugexc_vector are not used
>> anywhere so I have dropped these at the time of merging. Please
>> send separate patches to add these when they are being used
>> somewhere.
>> 
>> Reviewed-by: Anup Patel <anup at brainfault.org>
>> 
>> Applied this patch to the riscv/opensbi repo.
> 
> Uh I’m pretty sure this is a reset vector, and each label is naming the
> different entries in the vector, much like for mtvec.MODE=Vectored, and
> therefore the result of deleting those vector entries is that, if any
> of those cases occur, it will end up running whatever random code
> happens to be after the first entry.
> 
> I’ve noticed you are quite eager to modify people’s patches before
> applying them. Reformatting is one thing, but deleting assembly code is
> another that I think goes too far. Please be more considerate of the
> fact that you may not be correct in your interpretation, and so it is
> not appropriate to unilaterally commit whatever unreviewed changes you
> think are best, especially when it comes to vendor-specific code for
> which you haven’t read any of the corresponding manuals.

Especially since you keep the author intact, don’t add any kind of
Co-authored-by and don’t document any of the changes you have made
between the author’s Signed-of-by and yours. This means it looks like
it’s the submitter’s fault that there’s a bug in the commit, when in
reality they submitted a correct patch and you broke it. That’s not a
particularly nice thing to have done to one’s work.

Might I suggest, if the goal is to avoid the author needing to submit a
vN+1, at least confirm with the author that your intended fixes are
correct before folding them into the patch you commit? And, for more
minor cases, document that you’ve made changes, whether in the Linux
kernel committer style that states what you’ve actually done, or at
least by adding your own Co-authored-by to state you’ve done something
unspecified.

Jessica