Re: [PATCH 1/3] arm: Convert arm boot_lock to raw

[Russell King - ARM Linux <linux@armlinux.org.uk>]

On Sun, Dec 09, 2018 at 12:15:35AM +0100, Linus Walleij wrote:
> On Fri, Dec 7, 2018 at 2:00 PM Russell King - ARM Linux
> <linux@armlinux.org.uk> 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.

It's a "holding pen" - in normal parlence, it's a place where livestock
are temporarily confined.

In this case, our livestock are CPUs, and they are temporarily confined
in a tight loop.  Early ARM development boards did not have a way to
wake individual secondary CPUs from the boot loader, so the only way to
boot them as Linux wanted was to direct the boot loader to release all
CPUs into a "holding pen" and then release them from the holding pen
one at a time when Linux wanted a secondary CPU to come online.

The early systems also did not have very good bandwidth between the
CPUs and memory, which meant that the CPU requesting another core to
be plugged in would perturb the secondary core's delay calibration to
a noticable amount, and trapping the requesting core in a spinlock
would prevent the delay calibration going awry.

So, really _both_ these things are really really specific to ARM
development platforms, and have nothing to do with modern production
hardware.

No one should _ever_ copy the ARM reference platform SMP hotplug
code.  Needing that code is quite simply a sign that the platform is
quite simply not production hardware.

I really don't get how we've ended up with so many copies of this.
Maybe the code isn't being properly reviewed?  Maybe the process for
merging new platforms is way too lenient?  Whatever, the fact that
we're ending up with new copies of the pen release and boot lock
stuff demonstrably illustrates that the review process for new
platforms is very broken.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up