From: Shrikant Raskar <raskar.shree97@gmail.com>

Reorder header includes to follow kernel include
ordering conventions.

Signed-off-by: Shrikant Raskar <raskar.shree97@gmail.com>
---
 drivers/iio/proximity/rfd77402.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/proximity/rfd77402.c b/drivers/iio/proximity/rfd77402.c
index aff60a3c1a6f..69cc1505b964 100644
--- a/drivers/iio/proximity/rfd77402.c
+++ b/drivers/iio/proximity/rfd77402.c
@@ -10,9 +10,9 @@
  * https://media.digikey.com/pdf/Data%20Sheets/RF%20Digital%20PDFs/RFD77402.pdf
  */
 
-#include <linux/module.h>
-#include <linux/i2c.h>
 #include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
 
 #include <linux/iio/iio.h>
 

-- 
2.43.0

On Wed, Jan 21, 2026 at 02:05:41AM +0530, Shrikant Raskar via B4 Relay wrote:

> Reorder header includes to follow kernel include
> ordering conventions.

FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

On Wed, 21 Jan 2026 10:54:00 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Wed, Jan 21, 2026 at 02:05:41AM +0530, Shrikant Raskar via B4 Relay wrote:
> 
> > Reorder header includes to follow kernel include
> > ordering conventions.  
> 
> FWIW,
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> 

Patches 1 and 2 were already queued up.  I've rebuilt the merge
in my tree to drop patch 2 without breaking the rest of the history.

Shrikant, it is common for maintainer to pick up the early
part of a series whilst later parts still need more work.
If that happens, please rebase on the appropriate tree or
just drop those patches form your series that have already been
applied. Otherwise this mess happens where new review comes
in. Review is always good, but it should be clear if it
is on applied patches or not!

Jonathan

On Fri, Jan 23, 2026 at 2:27 AM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Wed, 21 Jan 2026 10:54:00 +0200
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>
> > On Wed, Jan 21, 2026 at 02:05:41AM +0530, Shrikant Raskar via B4 Relay wrote:
> >
> > > Reorder header includes to follow kernel include
> > > ordering conventions.
> >
> > FWIW,
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> >
>
> Patches 1 and 2 were already queued up.  I've rebuilt the merge
> in my tree to drop patch 2 without breaking the rest of the history.
>
> Shrikant, it is common for maintainer to pick up the early
> part of a series whilst later parts still need more work.
> If that happens, please rebase on the appropriate tree or
> just drop those patches form your series that have already been
> applied. Otherwise this mess happens where new review comes
> in. Review is always good, but it should be clear if it
> is on applied patches or not!
>
Sorry for creating the confusion, the patches 1 and 2 which were
applied in v4 were dropped from v5 onwards as per your suggestion.
Please see the links of the accepted patches for your reference.
1. https://lore.kernel.org/all/20260101-b4-rfd77402_irq-v4-1-42cd54359e9f@gmail.com/
2. https://lore.kernel.org/all/20260101-b4-rfd77402_irq-v4-2-42cd54359e9f@gmail.com/

As per reviewer comments , I have split the existing patches into
multiple commits like:
1. Added pre-cursor commit for include order
2. Added separate commit for devm mutex initialization
3. Added separate commit for kernel-doc for privata data.

Because of these separated commits, the total number of
patches in series are still 5.

Regards,
Shrikant

On Fri, 23 Jan 2026 09:12:31 +0530
Shrikant <raskar.shree97@gmail.com> wrote:

> On Fri, Jan 23, 2026 at 2:27 AM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Wed, 21 Jan 2026 10:54:00 +0200
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> >  
> > > On Wed, Jan 21, 2026 at 02:05:41AM +0530, Shrikant Raskar via B4 Relay wrote:
> > >  
> > > > Reorder header includes to follow kernel include
> > > > ordering conventions.  
> > >
> > > FWIW,
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> > >  
> >
> > Patches 1 and 2 were already queued up.  I've rebuilt the merge
> > in my tree to drop patch 2 without breaking the rest of the history.
> >
> > Shrikant, it is common for maintainer to pick up the early
> > part of a series whilst later parts still need more work.
> > If that happens, please rebase on the appropriate tree or
> > just drop those patches form your series that have already been
> > applied. Otherwise this mess happens where new review comes
> > in. Review is always good, but it should be clear if it
> > is on applied patches or not!
> >  
> Sorry for creating the confusion, the patches 1 and 2 which were
> applied in v4 were dropped from v5 onwards as per your suggestion.
> Please see the links of the accepted patches for your reference.
> 1. https://lore.kernel.org/all/20260101-b4-rfd77402_irq-v4-1-42cd54359e9f@gmail.com/
> 2. https://lore.kernel.org/all/20260101-b4-rfd77402_irq-v4-2-42cd54359e9f@gmail.com/
> 
> As per reviewer comments , I have split the existing patches into
> multiple commits like:
> 1. Added pre-cursor commit for include order
> 2. Added separate commit for devm mutex initialization
> 3. Added separate commit for kernel-doc for privata data.
> 
> Because of these separated commits, the total number of
> patches in series are still 5.
Ah ok so in general good. I guess you missed that I mailed to say I picked up a few
more in v5.
https://lore.kernel.org/all/20260116200921.7494025b@jic23-huawei/

These things happen so don't worry about it. I was just grumpy last night :(

Feeling much better now I've spent a few more hours getting on top of the
backlog for this cycle!

Jonathan
> 
> Regards,
> Shrikant
>