Hi Greg, On Thu, Oct 25, 2012 at 3:13 PM, Greg Kroah-Hartman <[email protected]> wrote: > 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 <[email protected]> >> > --- >> > 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, >
Ok, sure, will send patches to delete all these unused ones :) thanks. > greg k-h _______________________________________________ devel mailing list [email protected] http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
