[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aV101TrC5hB_nHJM@smile.fi.intel.com>
Date: Tue, 6 Jan 2026 22:47:17 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Shrikant <raskar.shree97@...il.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
David Lechner <dlechner@...libre.com>,
Nuno Sá <nuno.sa@...log.com>,
Andy Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, skhan@...uxfoundation.org,
david.hunter.linux@...il.com, linux-iio@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 4/4] iio: proximity: rfd77402: Add interrupt handling
support
On Tue, Jan 06, 2026 at 05:39:29AM +0530, Shrikant wrote:
...
> > > #include <linux/module.h>
> > > #include <linux/i2c.h>
> > > #include <linux/delay.h>
> > > +#include <linux/interrupt.h>
> > > +#include <linux/completion.h>
> > > #include <linux/iopoll.h>
> >
> > Same comment as per previous patch. Do not add even more misordering, please.
> Will it be okay if I re-order the includes as below ?
> #include <linux/completion.h>
> #include <linux/delay.h>
> #include <linux/i2c.h>
> #include <linux/interrupt.h>
> #include <linux/iopoll.h>
> #include <linux/module.h>
Just try to squeeze the new inclusions in the longest chain of the sorted ones
(yes, some original ones may be left untouched and hence unordered).
> #include <linux/iio/iio.h>
...
> > > +/**
> > > + * struct rfd77402_data - device-specific data for the RFD77402 sensor
> > > + * @client: I2C client handle
> > > + * @lock: mutex to serialize sensor reads
> > > + * @completion: completion used for interrupt-driven measurements
> > > + * @irq_en: indicates whether interrupt mode is enabled
> > > + */
> > > struct rfd77402_data {
> > > struct i2c_client *client;
> > > - /* Serialize reads from the sensor */
> > > struct mutex lock;
> > > + struct completion completion;
> > > + bool irq_en;
> > > };
> >
> > The kernel-doc conversion can be a separate patch, but I'm not insisting.
> I can split this into a separate patch within the same series.
> Please let me know if you would prefer it to be handled differently.
It's up to maintainers.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists