Re: [PATCH v4 00/36] HID: iio: basic clean up and introduce devm_ API for HID sensors

[Andy Shevchenko]

On Tue, May 26, 2026 at 04:56:51PM +0100, Jonathan Cameron wrote:
> On Mon, 25 May 2026 00:50:23 +0530
> Sanjay Chitroda <sanjayembeddedse@xxxxxxxxx> wrote:

> > Key highlights:
> > - 0000-0024: General cleanup and kernel few coding style fixes across HID IIO drivers
> > - 0025: Remove unused iio_dev argument from HID IIO sensor helper
> > - 0026: Introduce devm_hid_sensor_setup_trigger() device-managed API
> > - 0027-0036: Convert HID IIO sensor drivers to use the new devm-based trigger setup
> > 
> > changes in v4:
> > - Extend the series to cover remaining HID IIO drivers with devm API usage
> > - Reorder patches to place cleanup and warning fix at beginning and,
> >   devm-related changes toward the end based on feedback from David
> > - v3 series -> https://lore.kernel.org/all/20260509101040.791404-1-sanjayembedded@xxxxxxxxx/
> > changes in v3:
> > - Added cleanup and prepratory changes before adding devm_ API
> >   conversion based on self review: 0002, 0004, 0006, 0007 and 0008
> > - Address andy's review comment on commit message and coding style
> > - v2 series -> https://lore.kernel.org/all/20260429175918.2541914-1-sanjayembedded@xxxxxxxxx/
> > changes in v2:
> > - Following input from Jonathan and Andy, squash initial patch v1
> >   series in single change as individual change should not break anything
> > - Add devm API support and two driver using the same
> > - v1 series -> https://lore.kernel.org/all/20260428071613.1134053-1-sanjayembedded@xxxxxxxxx/
> > 
> > Testing:
> >   - Compiled with W=1 for each patch in series
> >   - Build-tested on QEMU x86_64
> > 
> > P.S.
> > - Sashiko reported an issue in a different driver and noted that it is not
> >   introduced by this series. I have taken this feedback into account and
> >   will address the actual issue in a separate series focus on that driver.
> > - Once this series is merged into the IIO tree, a number of HID IIO
> >   drivers will become available to fully converted to devm API usage.
> > - The changes are organized across drivers to keep similar modifications
> >   grouped together for consistency, making the series easier to review,
> >   rather than grouping all changes per driver.
> > 
> The series is mostly fine, though not sure what happened with how you sent
> it as I have it in seperate threads of 10 patches at a time. If you are having
> email troubles with big series, use b4 to send them instead (instructions on kernel.org)

I'm also confused. Fix your email and then come with better series chaining.

> My main concern is this is a lot of churn on a critical driver. I'd like therefore
> to be able to see the full benefit of those devm patches rather than get us
> part way as this does.


-- 
With Best Regards,
Andy Shevchenko