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

[Jonathan Cameron <jic23@kernel.org>]

On Tue, 28 Jan 2025 12:00:48 +0000
Lothar Rubusch <l.rubusch@gmail.com> wrote:

> 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.

So my main feedback here is to be much more reluctant to add new ABI.
Anything you add is unused by all existing code and if it is unique
to a driver probably never going to be used by anyone other than you.

We have a bunch of accelerometers in tree and as they go wrt to events
this one isn't even particularly complex.  The existing ABI covers
their events reasonably well so take a look at how they do it.  Often
it's a case of mapping names for the application of an event (free fall
detection, activity detection etc) to what what they are actually detecting.
Those generalize a lot better across different sensor types.  It's almost
always a threshold of some type. The tap / double tap are more complex
but we put quite a lot of effort into coming up with a general
description a year or so back.  There may new things but most of the
ABI is already there.

> 
> 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@gmail.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?

If you have an read modify write actions triggered by sysfs writes they
can race (not serialization between different file writes).
That's why you tend to need the mutex.

> 
> - 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?
I don't have it to hand but there is a patch set trying to add non
const versions of these that went to my other email.

For now just carry a local version as we don't want to end up waiting
for that patch to merge.

> 
> 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(-)
>