From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Anderson Date: Tue, 10 Mar 2020 09:16:22 -0400 Subject: [PATCH v6 13/19] riscv: Fix race conditions when initializing IPI In-Reply-To: References: <20200305181308.944595-1-seanga2@gmail.com> <20200305181308.944595-14-seanga2@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >> --- >> > >> 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