lkml.org 
[lkml]   [2017]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] staging: comedi: usbduxfast: Improve unlocking of a mutex in usbduxfast_ai_insn_read()
From
Date
>> @@ -838,6 +834,10 @@ static int usbduxfast_ai_insn_read(struct comedi_device *dev,
>>       mutex_unlock(&devpriv->mut);
>>         return insn->n;
>
> Minor niggle: You could also remove that call to mutex_unlock() by replacing the above three lines with:
>
>     ret = insn->n;
>
> which will fall through to the 'unlock:' label below.

Thanks for your suggestion.

Such a software refactoring is also possible if a corresponding
consensus could be achieved.
* Can such a change mean that the lock scope will be extended
for both use cases (successful and failed function execution)?

* How much does this implementation matter for you?

* Would you like to achieve a small reduction of the object code there?

* How do you think about consequences from special communication settings
by a well-known maintainer for my update suggestions?

Regards,
Markus

\
 
 \ /
  Last update: 2017-11-03 17:39    [W:0.071 / U:1.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site