[PATCH 1/7] Revert "riscv: Clear pending interrupts before enabling IPIs"

[Rick Chen]

Hi Sean

> On 9/9/20 3:50 AM, Rick Chen wrote:
> > Hi Sean
> >
> >> Clearing MIP doesn't do anything. Whoops. The following commits should
> >> tackle this problem in a more robust manner.
> >
> > I still not catch your points about that  this commit 947263033 really
> > help to fix  pending IPIs not clean problem on k210 platform at that
> > time, but you just said it do nothing and remove it here currently.
>
> After refactoring the original smp patch to remove the null check, I
> neglected to re-test with a debug uart enabled. Without doing that test,
> it is impossible to catch the pending IPI bug. The secondary hart will
> crash before the serial driver is initialized. I didn't do that test at
> the time, because I was mostly worried about the secondary hart
> corrupting the device tree and causing the boot to fail. That failure
> mode was fixed by 40686c394. So I saw that and thought that the pending
> IPI issue was solved as well.

Can you describe more clearly why with a debug uart enabled will
trigger the pending IPI bug ?

And why the pending IPI be raised and not clear before jump to U-Boot ?

Why the
csrc MODE_PREFIX(ip), t0
don't help to fix this bug ?

Thanks,
Rick


>
> --Sean
>
> >>
> >> This reverts commit 9472630337e7c4ac442066b5a752aaa8c3b4d4a6.
> >>
> >> Signed-off-by: Sean Anderson <seanga2 at gmail.com>
> >> ---
> >>
> >>  arch/riscv/cpu/start.S | 2 --
> >>  1 file changed, 2 deletions(-)
> >>
> >> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> >> index bf9fdf369b..e3222b1ea7 100644
> >> --- a/arch/riscv/cpu/start.S
> >> +++ b/arch/riscv/cpu/start.S
> >> @@ -65,8 +65,6 @@ _start:
> >>  #else
> >>         li      t0, SIE_SSIE
> >>  #endif
> >> -       /* Clear any pending IPIs */
> >> -       csrc    MODE_PREFIX(ip), t0
> >>         csrs    MODE_PREFIX(ie), t0
> >>  #endif
> >>
> >> --
> >> 2.28.0
> >>
>