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