Checkpatch warning:

WARNING: Missing a blank line after declarations
+	struct hts221_hw *hw = iio_priv(iio_dev);

Signed-off-by: Adi Nata <adinata.softwareengineer@gmail.com>
---
 drivers/iio/humidity/hts221_buffer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/humidity/hts221_buffer.c b/drivers/iio/humidity/hts221_buffer.c
index 4d03db19063e..c868549d09c0 100644
--- a/drivers/iio/humidity/hts221_buffer.c
+++ b/drivers/iio/humidity/hts221_buffer.c
@@ -194,6 +194,7 @@ static irqreturn_t hts221_buffer_handler_thread(int irq, void *p)
 int hts221_allocate_buffers(struct iio_dev *iio_dev)
 {
 	struct hts221_hw *hw = iio_priv(iio_dev);
+
 	return devm_iio_triggered_buffer_setup(hw->dev, iio_dev,
 					NULL, hts221_buffer_handler_thread,
 					&hts221_buffer_ops);
-- 
2.47.3

On Sun,  2 Aug 2026 10:06:13 +0800
Adi Nata <adinata.softwareengineer@gmail.com> wrote:

> Checkpatch warning:
> 
> WARNING: Missing a blank line after declarations
> +	struct hts221_hw *hw = iio_priv(iio_dev);
> 
> Signed-off-by: Adi Nata <adinata.softwareengineer@gmail.com>
> ---

This seems like churn on its own, Jonathan may not apply it.

Also, I feel like just putting checkpatch warnings directly into the
commit message is bad practice. Much better if it were "Add a blank line
after variable declarations per checkpatch warning."

-- 
Kind regards,
Joshua Crofts

On Sun, 2 Aug 2026 17:38:52 +0200
Joshua Crofts <joshua.crofts1@gmail.com> wrote:

> On Sun,  2 Aug 2026 10:06:13 +0800
> Adi Nata <adinata.softwareengineer@gmail.com> wrote:
> 
> > Checkpatch warning:
> > 
> > WARNING: Missing a blank line after declarations
> > +	struct hts221_hw *hw = iio_priv(iio_dev);
> > 
> > Signed-off-by: Adi Nata <adinata.softwareengineer@gmail.com>
> > ---  
> 
> This seems like churn on its own, Jonathan may not apply it.
> 

True.  This highlights a broader point.  When making
a number of cleanups to a driver (and I am generally more willing
to take those than many maintainers) please group them into
a little patch series with a cover letter.

If this is one of a set and overall the seem worthwhile I might
pick them up.  Plus this driver is pretty aged so there are other
quality of code / modernization things that will make much more
of an impact than just this blank line.  Take a look at some
of the other similar cleanup series on the IIO list and see what
makes sense here. To give you a starter, dev_err_probe() and
checking which prints are actually useful + stopping the driver
rejecting Device tree falllback compatibles because of the hard
fail on a device ID mismatch.

> 
> Also, I feel like just putting checkpatch warnings directly into the
> commit message is bad practice. Much better if it were "Add a blank line
> after variable declarations per checkpatch warning."

Fully agree with this.  We really don't care what the print is, just
what is being improved and why.

Thanks

Jonathan

On Mon, Aug 3, 2026 at 1:12 AM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Sun, 2 Aug 2026 17:38:52 +0200
> Joshua Crofts <joshua.crofts1@gmail.com> wrote:
>
>
> True.  This highlights a broader point.  When making
> a number of cleanups to a driver (and I am generally more willing
> to take those than many maintainers) please group them into
> a little patch series with a cover letter.
>
> If this is one of a set and overall the seem worthwhile I might
> pick them up.  Plus this driver is pretty aged so there are other
> quality of code / modernization things that will make much more
> of an impact than just this blank line.  Take a look at some
> of the other similar cleanup series on the IIO list and see what
> makes sense here. To give you a starter, dev_err_probe() and
> checking which prints are actually useful + stopping the driver
> rejecting Device tree falllback compatibles because of the hard
> fail on a device ID mismatch.
>
> >
> > Also, I feel like just putting checkpatch warnings directly into the
> > commit message is bad practice. Much better if it were "Add a blank line
> > after variable declarations per checkpatch warning."
>
> Fully agree with this.  We really don't care what the print is, just
> what is being improved and why.
>
> Thanks
>
> Jonathan
>

Hi Jonathan and Joshua,

Thank you for the advice. I will create a new patch series with a cover letter
for this hts221 driver accordingly based on your feedback.

Regards,
Adi Nata