On Thu, Oct 25, 2012 at 12:12:32PM -0700, Greg Kroah-Hartman wrote:
> On Thu, Oct 25, 2012 at 01:50:58AM -0400, Devendra Naga wrote:
> > when down_interruptible fail, means a signal occur, or any other failure
> > we are panicing, and it seems that we should not panic, instead we would
> > have done a spinlock, but currently removing the panic call.
> >
> > Signed-off-by: Devendra Naga <devendra.aaru@xxxxxxxxx>
> > ---
> > drivers/staging/csr/csr_framework_ext.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/staging/csr/csr_framework_ext.c b/drivers/staging/csr/csr_framework_ext.c
> > index e203f60..e62878e 100644
> > --- a/drivers/staging/csr/csr_framework_ext.c
> > +++ b/drivers/staging/csr/csr_framework_ext.c
> > @@ -82,7 +82,6 @@ CsrResult CsrMutexLock(CsrMutexHandle *mutexHandle)
> >
> > if (down_interruptible(mutexHandle))
> > {
> > - CsrPanic(CSR_TECH_FW, CSR_PANIC_FW_UNEXPECTED_VALUE, "CsrMutexLock Failed");
>
> This is fine, I'll remove this. But notice that no one ever calls
> CsrMutexLock() so you can just remove this whole function now as well.
> Can you send a follow-on patch to do that?
Oh, same thing goes for CsrPanic() itself, no one calls it (the macro it
is used in isn't called anywhere either, so it can be removed.) It's a
nice trail of things you can just delete from this driver that you are
starting down here :)
thanks,
greg k-h
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
