On Fri, Dec 7, 2018 at 2:00 PM Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> wrote: > I think the bigger question is why are all these platforms using this. > For the ARM development platforms, it's fair as they have no way to > power down the CPUs or reset the other CPUs, and the "boot lock" was > there originally to prevent the delay calibration going awry. (I've > been saying this for years but obviously people like to stuff their > fingers in their ears.) > > It annoys me when people cargo-cult copy code and don't bother trying > to understand it, which is shown clearly in your diffstat. It's a very good point. I did away with "my" culprit at one point in commit c00def71efd9 "ARM: ux500: simplify secondary CPU boot" so people could look at that for an example to see how pointless this "pen holding" (what does it even mean, I never figured it out?) and boot_lock is. I thought it was just a few platforms around the time the first SMP systems were arriving that were doing this but as you point out, recent newcomers are doing this, such as sti, actions, qcom, hisi, sunxi. I would encourage other platforms that have this "write some magic stuff in some register to boot cpu n" to look at arch/arm/mach-ux500/platsmp.c, something like that should be all you need, no special assembly, no "pen", no "boot lock". Look up resources etc in .smp_prepare_cpus(), make sure to call set_cpu_possible() for each available CPU, then just kick in the CPU n in .smp_boot_secondary() by doing your platform magic. Optionally cpu_die() if you need special code or just put in a wfi() for that. That's all. Yours, Linus Walleij
