Re: [PATCH 2/4] sparc32: wait for secondary CPUs by time, not by loop count

From: Ramin Moussavi

Date: Thu Oct 15 2026 - 09:43:39 EST


On Thu, Oct 15, 2026, at 11:09, Arnd Bergmann wrote:
> The patch is not wrong, but having a broken udelay() is still problematic
> in other places, so it may be better to fix that instead.
>
> On most modern targets, we tend to just use the cycle counter if the
> frequency is known and avoid the delay loop calibration entirely.
> Any reason that sparc32 still needs the calibration?

It could probably be solved with the hardware timers, the ones
timer_cs already uses.

I agree that this would be the better fix, and I could try a udelay()
based on a hardware timer. But I only have qemu here, no real sparc32
hardware, so I would rather not change udelay() for real machines on
my own. If someone with hardware can test it, I would be glad to do it
as a separate series.

Until then I would keep this patch: it is small, does not depend on
udelay() being right, and fixes the boot hang for stable on qemu.

Regards,
Ramin