> Switching to scoped_guard simplifies the code and avoids to take care to > unlock the mutex in case of premature return. Can such a change description become more imperative? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.10-rc6#n94 … > +++ b/drivers/iio/adc/ad7606.c … > @@ -124,19 +122,19 @@ static irqreturn_t ad7606_trigger_handler(int irq, void *p) … > ret = ad7606_read_samples(st); > - if (ret == 0) > - iio_push_to_buffers_with_timestamp(indio_dev, st->data, > - iio_get_time_ns(indio_dev)); > + if (ret) > + goto error_ret; > > + iio_push_to_buffers_with_timestamp(indio_dev, st->data, > + iio_get_time_ns(indio_dev)); > +error_ret: > iio_trigger_notify_done(indio_dev->trig); … I find that these control flow adjustments do not fit to the changelog. They can be offered in another update step (on demand), can't they? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.10-rc6#n81 There are no scoped_guard() calls performed in your patch. How do you think about to use a summary phrase like “Switch mutex calls to mutex guard usage”? Regards, Markus
