[PATCH 07/16] ARM: bL_platsmp.c: close the kernel entry gate before hot-unplugging a CPU
Will Deacon
will.deacon at arm.com
Mon Jan 14 12:23:26 EST 2013
On Mon, Jan 14, 2013 at 05:15:07PM +0000, Nicolas Pitre wrote:
> On Mon, 14 Jan 2013, Will Deacon wrote:
> > On Mon, Jan 14, 2013 at 04:53:41PM +0000, Nicolas Pitre wrote:
> > > The bL_set_entry_vector() includes a cache flush which itself has a DSB.
> > > Hence my previous interrogation.
> >
> > For L1, sure, we always have the dsb for v7. However, for the outer-cache we
> > only have a dsb by virtue of a spin_unlock in l2x0.c... it seems a bit risky
> > to rely on that for ordering your entry_vector write with the power_on.
> >
> > I think the best bet is to put a barrier in power_on, before invoking the
> > platform_ops function and similarly for power_off.
> >
> > What do you reckon?
>
> I much prefer adding barriers inside the API when they are needed for
> proper execution of the API intent. So if I call bL_set_entry_vector(),
> I trust that by the time it returns the vector is indeed set and ready
> for use by other processors.
>
> The same could be said about the outer cache ops. If a DSB is needed
> for their intent to be valid, then why isn't this DSB always implied by
> the corresponding cache op calls? And as you say, there is already one
> implied by the spinlock used there, so that is not if things would
> change much in practice.
Ok, so we can fix the outer_cache functions as suggested by Catalin. That
still leaves the GIC CPU interface problem in the later patch, which uses a
writel_relaxed to disable the CPU interface, so I suppose we can just put
a dsb at the end of gic_cpu_if_down().
Will
More information about the linux-arm-kernel
mailing list