Two of the four tasks in the TODO comment have been implemented.

Interrupts were added by commit ffe0ab6a9698 ("iio: accel:
bma400: Add triggered buffer support"). Support for events was added by
commit 961db2da159d ("iio: accel: bma400: Add support for single and
double tap events"), among others. The driver now has an interrupt
handler pushing IIO events, and event configuration from
read_event_config(), write_event_config(), read_event_value(), and
write_event_value().

A step count channel was also added by commit d221de60eee3 ("iio: accel:
bma400: Add separate channel for step counter").

The power management and sensor time channel TODOs remain unimplemented.

Signed-off-by: Marco Chen <marcochen.dev@gmail.com>
---
I would like to take on the remaining power management TODO. The driver
has bma400_set_power_mode() but neither bus assigns a dev_pm_ops
struct. POWER_MODE_LOW is also never entered. I don't have a BMA400 but
I would definitely buy one to develop and test on. I also have access to
a logic analyzer for testing. Is this a patch that is desirable?

 drivers/iio/accel/bma400_core.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/iio/accel/bma400_core.c b/drivers/iio/accel/bma400_core.c
index 7e3cff4cca91..6bc64ca87f4b 100644
--- a/drivers/iio/accel/bma400_core.c
+++ b/drivers/iio/accel/bma400_core.c
@@ -6,8 +6,6 @@
  *
  * TODO:
  *  - Support for power management
- *  - Support events and interrupts
- *  - Create channel for step count
  *  - Create channel for sensor time
  */
 
-- 
2.55.0

On Thu, 13 Aug 2026 11:01:03 -0400
Marco Chen <marcochen.dev@gmail.com> wrote:

> Two of the four tasks in the TODO comment have been implemented.
> 
> Interrupts were added by commit ffe0ab6a9698 ("iio: accel:
> bma400: Add triggered buffer support"). Support for events was added by
> commit 961db2da159d ("iio: accel: bma400: Add support for single and
> double tap events"), among others. The driver now has an interrupt
> handler pushing IIO events, and event configuration from
> read_event_config(), write_event_config(), read_event_value(), and
> write_event_value().
> 
> A step count channel was also added by commit d221de60eee3 ("iio: accel:
> bma400: Add separate channel for step counter").
> 
> The power management and sensor time channel TODOs remain unimplemented.
> 
> Signed-off-by: Marco Chen <marcochen.dev@gmail.com>
> ---
> I would like to take on the remaining power management TODO. The driver
> has bma400_set_power_mode() but neither bus assigns a dev_pm_ops
> struct. POWER_MODE_LOW is also never entered. I don't have a BMA400 but
> I would definitely buy one to develop and test on. I also have access to
> a logic analyzer for testing. Is this a patch that is desirable?

Strange that these weren't removed in the commits that introduce said
changes... Anyhow, not sure if this patch on its own is too much churn,
Jonathan and the other usually prefer these to go in a series of more
changes (i.e. if you do the power management TODO, you send this patch
in the series). This is up to Jonathan however.

-- 
Kind regards,
Joshua Crofts

On Mon, Aug 17, 2026 at 04:15:23PM +0200, Joshua Crofts wrote:

> Strange that these weren't removed in the commits that introduce said
> changes... Anyhow, not sure if this patch on its own is too much churn,
> Jonathan and the other usually prefer these to go in a series of more
> changes (i.e. if you do the power management TODO, you send this patch
> in the series). This is up to Jonathan however.

That makes sense. I will resend this patch as part of a power management
series instead of an individual patch like I did here. I have ordered
a bma400 and I am reading the kernel docs on runtime PM and other IIO
drivers on how they implement it. 

To Jonathan, do you have a preference on how the power management
series should be structured?

On Thu, 20 Aug 2026 11:37:49 -0400
Marco Chen <marcochen.dev@gmail.com> wrote:

> On Mon, Aug 17, 2026 at 04:15:23PM +0200, Joshua Crofts wrote:
> 
> > Strange that these weren't removed in the commits that introduce said
> > changes... Anyhow, not sure if this patch on its own is too much churn,
> > Jonathan and the other usually prefer these to go in a series of more
> > changes (i.e. if you do the power management TODO, you send this patch
> > in the series). This is up to Jonathan however.  
In this case it is tidying up now incorrect documentation. I'm fine
with doing that on it's own.  Hence applied.


> 
> That makes sense. I will resend this patch as part of a power management
> series instead of an individual patch like I did here. I have ordered
> a bma400 and I am reading the kernel docs on runtime PM and other IIO
> drivers on how they implement it. 
> 
> To Jonathan, do you have a preference on how the power management
> series should be structured?

Sorry - I'm way behind on review so not going to have time to look at
the datasheet or driver for a few weeks at least.  Perhaps share a proposal
and we can look at it on list.

Jonathan

> 
>