>> @@ -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 -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
