linux-kernel - Re: [PATCH v4 10/11] iio: accel: adxl313: add AC coupled activity/inactivity 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFXKEHZj7nYOJA7Ztxh8xiOcPpwDNBzNyN830tiKL=7rL0fiug@mail.gmail.com>
Date: Wed, 11 Jun 2025 21:58:36 +0200
From: Lothar Rubusch <l.rubusch@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: dlechner@...libre.com, nuno.sa@...log.com, andy@...nel.org, corbet@....net, 
	lucas.p.stankus@...il.com, lars@...afoo.de, Michael.Hennerich@...log.com, 
	bagasdotme@...il.com, linux-iio@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 10/11] iio: accel: adxl313: add AC coupled
 activity/inactivity events

Hi Jonathan,

On Sun, Jun 8, 2025 at 6:23 PM Jonathan Cameron <jic23@...nel.org> wrote:
>
> On Sun,  1 Jun 2025 17:21:38 +0000
> Lothar Rubusch <l.rubusch@...il.com> wrote:
>
> > Add AC coupling activity and inactivity as MAG_ADAPTIVE events. This adds
> > up an additional set of threshold and period handles, verifies matching
> > disabling functionality and extends setting the link bit to complementary
> > event configurations.
> >
> > This means, e.g. either ACTIVITY or ACTIVITY_AC can be enabled. The most
> > recent set will remain configured. Disabling ACTIVITY where ACTIVITY_AC was
> > enabled is ignored, since it does not match (should be disabling
> > ACTIVITY_AC). When INACTIVITY or INACTIVITY_AC is also enabled, the link
> > bit will be set. Note, having the link bit and auto-sleep in place activity
> > and inactivity indicate the power save state change and thus will only be
> > triggered once a state transition occurs. Since there is a separate AC bit
> > for ACTIVITY and for INACTIVITY, events can be linked independently from
> > each other i.e. ACTIVITY can be linked to INACTIVITY_AC for instance.
> >
> > When one of both is disabled, the link bit will be removed. Hence, the
> > remaining event will not indicate a plain state change anymore, but occur
> > as a periodically triggered inactivity event or for each activity event
> > above the threshold.
> >
> > Signed-off-by: Lothar Rubusch <l.rubusch@...il.com>
>
> Minor thought on rereading this.  If we don't have the link bit set
> (and the paired event) the AC events are more accurately described as
> MAG_REFERENCED as they are referenced simply to whatever acceleration
> was going on when they were first enabled.   Only with the link bit
> set (and the other event type enabled) are they actually adapting
> (so MAG_ADAPTIVE).
>

Going by examples, I can follow you as practically I'm aware of the
difference between a plain inactivity setup and a link-bit enabled
inactivity(and activity) setup. Initially I thought of MAG and the
AC-coupled equivalent being MAG_REFERENCED. By your explanation I
understand why you preferred MAG_ADAPTIVE rather. But still all three
configurations are possible.

My idea is, the driver implementation supports all cases in parallel,
at least to a certain extent. I mean, at the current implementation
someone can configure plain activity, or AC-coupled activity, or
respectively, their inactivity equivalents - when both, an activity
type together with an inactivity type are enabled, they will be linked
counter events. I.e. "adaptive" - and auto-sleep will be turned on for
the inactivity periods. Built on using just plain IIO API w/o custom
API calls.

Due to all the possible combinations, this comes at a certain
complexity. In terms of configuration and for instance mapping to MAG,
MAG_REFERNCED or MAG_ADAPTIVE. Here I rely on your feedback. On my
side, I'll try to recycle the automation setup to verify registers are
configured as I like them to be using the sysfs handles (that's btw
the reason why I'm glad to have debugfs on board). So, if you tell me,
to change it rather to MAG_REFERENCED, I'll do it, but then AC-coupled
events will be all MAG_REFRENCED w/ or w/o link bit. Or we come up
with a total different approach, like putting link-bit AC on
MAG_ADAPTIVE and plain AC-coupled on MAG_REFERENCED, but then what
about MAG events w/ or w/o link-bit? hmm, I think current approach
seems to be a good compromise. Let me know what you think.

Best,
L

>
> Maybe there is room to use that to ultimately control whether the
> link bit is set or not (putting aside the power aspect of that).
>