On Sun, May 25, 2025 at 2:50 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > On Fri, 23 May 2025 22:35:11 +0000 > Lothar Rubusch <l.rubusch@xxxxxxxxx> 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
