Message-ID: <CAFXKEHbksqY9Xn-0SCHbUmU-YOR2y0TqDXZFtc-ARA+gXNd4Xg@mail.gmail.com>
Date: Sun, 25 May 2025 16:54:11 +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, 
	linux-iio@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 00/12] iio: accel: adxl313: add power-save on activity/inactivity

On Sun, May 25, 2025 at 2:50 PM Jonathan Cameron <jic23@...nel.org> wrote:
>
> On Fri, 23 May 2025 22:35:11 +0000
> Lothar Rubusch <l.rubusch@...il.com> wrote:
>
> > The patch set covers the following topics:
> > - add debug register and regmap cache
> > - prepare iio channel scan_type and scan_index
> > - prepare interrupt handling
> > - implement fifo with watermark
> > - add activity/inactivity together with auto-sleep with link bit
> > - documentation
> >
> > Since activity and inactivity here are implemented covering all axis, I
> > assumed x&y&z. Thus the driver uses a fake channel for activity/inactiviy.
>
> Hi Lothar,
>
> I think on this occasion you were a bit too speedy in sending out a new
> version.  Might have been better to wait at least 1-2 weeks at this point
> in the cycle, or until you had a few more reviews in at least.
>
> I don't mind that much, but it does create noise on the list and tends
> to reduce the focus patch sets get a little.
>

Hi Jonathan & ML, thank you for this hint.

I assumed Andy was just "taking over" here. In consequence the rounds
were based on his reviews. For the future, I better await your (any
IIO maintainers') reviews, until going into next round?
I accept how you like to work on this. Nevertheless, isn't it more
efficient when I resubmit right after Andy's review (if I can), then
you review and I re-submit again? In this case I would go through my
codes thoroughly twice, which usually improves quality of the result,
IMHO. Since only the most recent version of my patches should actually
be considered, the older ones could simply be ignored (not sure if it
is possible to flag this somenow from your maintainer side). I can see
the point, though, where this increases the number of mails on the
list. Nvm, just an idea. I'll wait in future.

ADXL313: I neither care much about the number of rounds, nor about the
split of patches. Thus I split rather a bit too much and you tell me
how I shall merge (I think that's easier than sending you in a big
blob patch and figuring out then what and how to separate). Pls, let
me know if you oppose to this approach?

BTW, I also still had a more recent version of the ADXL345 series,
containing the freefall and inactivity story. Current
question/proposal: Freefall and inactivity, send out the same MAG
event. An Idea could be, that userland software simply has logic to
distinguish on timing, but the kernelspace driver here is doing just
the same IIO event.

Long story short - I shifted freefall to the end (also in oder to
easily rather exclude it from that series). I expect this NOT to be
the final round. First, there is the freefall situation (actually I
expect objections from your side. If so, I'll exclude freefall from
here). Second, by some of Andys reviews I feel I also should improve
the ADXL345 a bit. I learned about regmap_assign_bits() which comes in
very handy. So, if you tell me the freefall approach in ADXL345 is
nonsense, I'll exclude it from this series.

Best,
L


> Jonathan

Powered by blists - more mailing lists