This series adds support for step counter and motion events using
interrupts in the BMI270 driver.

The step counter can be enabled, disabled, and configured with a
watermark, all from userspace.

Any-motion and no-motion events are generated by detecting changes
in acceleration on each axis.

Signed-off-by: Gustavo Silva <gustavograzs@gmail.com>
---
Sorry for the delay in sending v5.
As a reminder, patches 1 and 2 were already accepted in v3.

Changes in v5:
- BMI270_G_MACRO_M_S_2 -> BMI270_G_MICRO_M_S_2
- Add patch #4: ABI documentation for the exposed sysfs attributes
Link to v4: https://lore.kernel.org/r/20250711-bmi270-events-v4-3-53ec7da35046@gmail.com

Changes in v4:
- Reworked the threshold for the any-motion event so that threshold *
  accel_scale is given in m/s^2, in accordance with the ABI
  Also the range of available values for the threshold is now determined
  dynamically based on the value of the accelerometer scale
- Fixed alignment and styling of some statements and macros
- Simplified the return statement in the bmi270_read_event_config()
  function by returning the boolean expression directly
- Link to v3: https://lore.kernel.org/r/20250616-bmi270-events-v3-0-16e37588604f@gmail.com

Changes in v3:
- Avoid the usage of set_mask_bits() macro on 16-bit integers,
  use the bitwise operators instead
- Fix indentation, alignment and style issues
- Link to v2: https://lore.kernel.org/r/20250605-bmi270-events-v2-0-8b2c07d0c213@gmail.com

Changes in v2:
- Reduce the scope of mutex lock when clearing the step counter
- Change the type of the 'steps_enabled' variable from int to bool
- Add a new DMA safe variable to the device's private data to access the
  feature registers
- Remove unnecessary mutex lock
- Fix a build error found by the kernel test robot by initializing a
  local variable in the `bmi270_update_feature_reg()` function
- Remove dead code in the `bmi270_write_event_config()` function
- Add macro definitions and corresponding datasheet references for
  relevant constants: step counter maximum value, step counter factor,
  and threshold upper limit
- Remove the event bitmask from the device's private data. Read the
  registers directly to retrieve this information instead
- Use IIO_UNMOD_EVENT_CODE instead of IIO_MOD_EVENT_CODE where
  appropriate
- Fix shadowed error codes
- Change motion event to be enabled on a per-axis basis
- Create pseudo channel of type accel_x&y&z for the no-motion event
- Change no-motion event type to IIO_EV_TYPE_ROC
- Link to v1: https://lore.kernel.org/r/20250424-bmi270-events-v1-0-a6c722673e5f@gmail.com

---
Gustavo Silva (2):
  iio: imu: bmi270: add support for motion events
  iio: ABI: document accel and roc event attributes

 Documentation/ABI/testing/sysfs-bus-iio |  40 +++
 drivers/iio/imu/bmi270/bmi270_core.c    | 384 ++++++++++++++++++++++--
 2 files changed, 404 insertions(+), 20 deletions(-)


base-commit: 91812d3843409c235f336f32f1c37ddc790f1e03
-- 
2.51.0

On Sat, Aug 30, 2025 at 2:58 PM Gustavo Silva <gustavograzs@gmail.com> wrote:
>
> This series adds support for step counter and motion events using
> interrupts in the BMI270 driver.
>
> The step counter can be enabled, disabled, and configured with a
> watermark, all from userspace.
>
> Any-motion and no-motion events are generated by detecting changes
> in acceleration on each axis.
>

> Sorry for the delay in sending v5.
> As a reminder, patches 1 and 2 were already accepted in v3.

Right, and this series has confusing patch numbering. Please, make
sure you send all the patches that are mentioned in the numbers, or
correct numbers. I even don't know if `b4` by default can handle this
(yes, it can if one manually passes the numbers of the patches to
take).

-- 
With Best Regards,
Andy Shevchenko

On Sat, 30 Aug 2025 15:36:52 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Sat, Aug 30, 2025 at 2:58 PM Gustavo Silva <gustavograzs@gmail.com> wrote:
> >
> > This series adds support for step counter and motion events using
> > interrupts in the BMI270 driver.
> >
> > The step counter can be enabled, disabled, and configured with a
> > watermark, all from userspace.
> >
> > Any-motion and no-motion events are generated by detecting changes
> > in acceleration on each axis.
> >  
> 
> > Sorry for the delay in sending v5.
> > As a reminder, patches 1 and 2 were already accepted in v3.  
> 
> Right, and this series has confusing patch numbering. Please, make
> sure you send all the patches that are mentioned in the numbers, or
> correct numbers. I even don't know if `b4` by default can handle this
> (yes, it can if one manually passes the numbers of the patches to
> take).
> 
Absolutely agree. Don't worry about patch numbers matching cross
versions. It's common for them to change for this reason or because
things got split up, merged, spun around etc so normally we make no
attempt to keep them constant.

J