[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120517205003.GE16397@linux-mips.org>
Date: Thu, 17 May 2012 22:50:03 +0200
From: Ralf Baechle <ralf@...ux-mips.org>
To: David Daney <ddaney.cavm@...il.com>
Cc: Yong Zhang <yong.zhang0@...il.com>, linux-rt-users@...r.kernel.org,
linux-kernel@...r.kernel.org, david.daney@...ium.com,
tglx@...utronix.de
Subject: Re: [PATCH -rt] MIPS: Octeon: convert smp_reserve_lock to raw
spinlock
On Thu, May 17, 2012 at 09:30:42AM -0700, David Daney wrote:
> Date: Thu, 17 May 2012 09:30:42 -0700
> From: David Daney <ddaney.cavm@...il.com>
> To: Yong Zhang <yong.zhang0@...il.com>, ralf@...ux-mips.org
> CC: linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org,
> david.daney@...ium.com, tglx@...utronix.de
> Subject: Re: [PATCH -rt] MIPS: Octeon: convert smp_reserve_lock to raw
> spinlock
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 05/17/2012 03:15 AM, Yong Zhang wrote:
> >From: Yong Zhang<yong.zhang@...driver.com>
> >
> >Because __cpu_disable is called in atomic context and spinlock
> >is a mutex on -rt.
> >
> >Signed-off-by: Yong Zhang<yong.zhang0@...il.com>
> >---
> > arch/mips/cavium-octeon/smp.c | 6 +++---
> > 1 files changed, 3 insertions(+), 3 deletions(-)
> >
> >diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
> >index ef9c34a..473c72b 100644
> >--- a/arch/mips/cavium-octeon/smp.c
> >+++ b/arch/mips/cavium-octeon/smp.c
> >@@ -257,7 +257,7 @@ DEFINE_PER_CPU(int, cpu_state);
> >
> > extern void fixup_irqs(void);
> >
> >-static DEFINE_SPINLOCK(smp_reserve_lock);
> >+static DEFINE_RAW_SPINLOCK(smp_reserve_lock);
> >
>
> Ralf added this in 773cb77d (MIPS: Cavium: Add CPU hotplugging code.)
>
> I'm not even sure what this lock is supposed to be protecting, so I
> would like Ralf to take a look.
>
> You can add an Acked-by: from me for either this patch as is, or if
> Ralf thinks it is OK, removing the lock entirely.
>
> In any event we can merge this via Ralf's tree.
The 773cb77d patch has a long history but I think I first worked on it for
Wind River Linux 2.0 which was 2.6.21-based, then broke it out and pushed
it upstream. In 2.6.21 it was probably infected by the the smp_reserve_lock
virus in the s390 code for no good reason. So I agree, the lock can
be dropped and I'm queueing a patch to do so for 3.5.
Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists