Message-ID: <20250208125732.2a41961a@jic23-huawei>
Date: Sat, 8 Feb 2025 12:57:32 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Lothar Rubusch <l.rubusch@...il.com>
Cc: lars@...afoo.de, Michael.Hennerich@...log.com,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 eraretuya@...il.com
Subject: Re: [PATCH v1 00/12] iio: accel: adxl345: add interrupt based
 sensor events

On Tue, 4 Feb 2025 14:40:17 +0100
Lothar Rubusch <l.rubusch@...il.com> wrote:

> Hi Jonathan, please find my answers below.
> 
> On Sat, Feb 1, 2025 at 6:48 PM Jonathan Cameron <jic23@...nel.org> wrote:
> >
> > On Tue, 28 Jan 2025 12:00:48 +0000
> > Lothar Rubusch <l.rubusch@...il.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.
> >  
> Please, understand my patches in "v1" rather as a huge set of questions,
> than a proposal of reinventing the IIO ABI :)
> My intention is actually not to extend/rewrite the ABI. It rather shows my lack
> of knowledge combined with the curiosity of how to actually use the
> (IIO) APIs for
> such implementation. I know this is still tedious, but I'm sure it will become
> better.
> 
> My dilemma was/is the following: I did an initial implementation more similar
> to e.g. ADXL380 for such events, and the sca3000.c for the freefall event.
> IMHO the names for the sysfs handles were not at all intuitively mappable to the
> fields I liked to operate, such as tap duration, window, latent, etc.
> The other alternative I saw, was setting up sysfs myself, IMHO clearer naming
> but actually not really using IIO's event_config/event_value.
> 
> Personally, I don't have any preference. If there really is no way to change
> naming of the sysfs handles, then it's probably a question of
> documentation. If I
> can make it more intuitive for a user who knows the sensor, but not
> the internals
> of IIO, then I'd prefer to use the names referred and documented in the sensor's
> datasheet.

ABI has to be consistent across lots of different device types.  Things
that on accelerometers mean freefall are totally different for ADCs etc.
That's one of the challenges of an ABI that is meant to cover many devices.
There is also the challenge that one devices idea of how to detect what seems
like a common thing can be totally different to another with controls
that don't line up at all.  By targetting what is actually being measured
rather than what the device datasheet says it is for, we tend to get better
generalisation and more meaningful control parameters.  It gets fiddly
around things that are sort of dumb classifiers like tap detectors
or more complex activity classifiers as we don't always get useful
documentation on what the controls are doing.

Many users will make use of userspace libraries. If they are focused on
just accelerometers they get to present an interface to the next layer
up that is accelerometer specific.


> 
> In summary, I see your point. So, I redo this patch set as I did in the initial
> approach to show better what I mean. Probably I'm just using it in a wrong way.
> Thank you for the feedback so far, I'll try to use it where it still applies.

Feel free to send out an ABI RFC in cases where it's not obvious.  That
can save some time by getting at least outline agreement on the direction
before code is ready.


Jonathan

Powered by blists - more mailing lists