>> @@ -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 _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
