[PATCH v6 13/19] riscv: Fix race conditions when initializing IPI

[Sean Anderson]

On 3/10/20 4:20 AM, Rick Chen wrote:
> Hi Sean
> 
>> The IPI code could have race conditions in several places.
>> * Several harts could race on the value of gd->arch->clint/plic
>> * Non-boot harts could race with the main hart on the DM subsystem In
>>   addition, if an IPI was pending when U-Boot started, it would cause the
>>   IPI handler to jump to address 0.
>>
>> To address these problems, a new function riscv_init_ipi is introduced. It
>> is called once during arch_cpu_init_dm. Before this point, no riscv_*_ipi
>> functions may be called. Access is synchronized by gd->arch->ipi_ready.
>>
>> Signed-off-by: Sean Anderson <seanga2 at gmail.com>
>> ---
>>
> 
>> Can you try to clear mip/sip in startup flow before secondary_hart_loop:
>> Maybe it can help to overcome the problem of calling riscv_clear_ipi()
>> before riscv_init_ipi() that you added.
> 
> How is the verified result about trying to clear mip/sip in startup flow ?
> I have asked you twice in v5, but you still have no response about it.
> 
> [PATCH v5 27/33] riscv: Fix race conditions when initializing IPI
> https://patchwork.ozlabs.org/patch/1246864/#2377119
> 
> Thanks
> Rick

I managed to get it working, and this patch incorporates that change.
However, I forgot to update the commit message. The original issue I had
was related to an accidental change to my config, and not to the
clearing of MIP.

--Sean