linux-kernel - [PATCH v1 00/12] iio: accel: adxl345: add interrupt based sensor events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250128120100.205523-1-l.rubusch@gmail.com>
Date: Tue, 28 Jan 2025 12:00:48 +0000
From: Lothar Rubusch <l.rubusch@...il.com>
To: lars@...afoo.de,
	Michael.Hennerich@...log.com,
	jic23@...nel.org
Cc: linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	eraretuya@...il.com,
	l.rubusch@...il.com
Subject: [PATCH v1 00/12] iio: accel: adxl345: add interrupt based sensor events

Add several interrupt based sensor detection events:
- single tap
- double tap
- free fall
- activity
- inactivity

All the needed parameters for each and methods of adjusting them, and
forward a resulting IIO event for each to the IIO channel.

The sensor has further features still not covered:
- g-ranges scaled by different ODRs, especially for activity / inactivity
  threshold is not covered so far. There seems to be a particularity with
  the ADXL345 as annotated on some analog FAQ.

- Various thinks like low power, sleep mode, etc. are (still) not covered
  here, others (ACDC bit, selftest, etc.) currently are hard coded or not
  covered.

Signed-off-by: Lothar Rubusch <l.rubusch@...il.com>
---
Questions:
- Do I need a mutex/lock protection as this is the case e.g. in the ADXL367
  or the ADXL380?
  Actually, I understand those cases as protecting access to the state
  object by different channels, temperature and accelerometer. I'm unsure
  if this is a correct understanding, where for the ADXL345 there should
  not be any issue. At most, a currently displayed value on sysfs is
  (still) not updated. So, IMHO I can rely on the internal protections in
  regmap no further mutex is needed. Please, can you give me a feedback
  here?

- FIELD_PREP/FIELD_GET: I'd like to use arrays of enum indexed elements
  to allow for more generic function implementation passing just a "type"
  field, e.g. at single tap/double tap or activity/inactivity handling.
  When it comes to filtering out bits using FIELD_GET/FIELD_PREP, it says
  that this enum array element is not "const enough". Is there a
  work-around?

Lothar Rubusch (12):
  iio: accel: adxl345: migrate constants to core
  iio: accel: adxl345: reorganize measurement enable
  iio: accel: adxl345: add debug register access
  iio: accel: adxl345: reorganize irq handler
  iio: accel: adxl345: improve access to the interrupt enable register
  iio: accel: adxl345: add single tap feature
  iio: accel: adxl345: show tap status and direction
  iio: accel: adxl345: add double tap feature
  iio: accel: adxl345: add double tap suppress bit
  iio: accel: adxl345: add freefall feature
  iio: accel: adxl345: add activity feature
  iio: accel: adxl345: add inactivity feature

 drivers/iio/accel/adxl345.h      |   86 ---
 drivers/iio/accel/adxl345_core.c | 1150 ++++++++++++++++++++++++++++--
 2 files changed, 1099 insertions(+), 137 deletions(-)

-- 
2.39.5