Add accelerometer and rate of change event-related sysfs attributes
exposed by the bmi270 driver.
Signed-off-by: Gustavo Silva <gustavograzs@gmail.com>
---
Documentation/ABI/testing/sysfs-bus-iio | 40 +++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 2fb2cea4b192..75a88f0dc533 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -908,6 +908,7 @@ What: /sys/.../iio:deviceX/events/in_accel_y_roc_rising_en
What: /sys/.../iio:deviceX/events/in_accel_y_roc_falling_en
What: /sys/.../iio:deviceX/events/in_accel_z_roc_rising_en
What: /sys/.../iio:deviceX/events/in_accel_z_roc_falling_en
+What: /sys/.../iio:deviceX/events/in_accel_x&y&z_roc_rising_en
What: /sys/.../iio:deviceX/events/in_anglvel_x_roc_rising_en
What: /sys/.../iio:deviceX/events/in_anglvel_x_roc_falling_en
What: /sys/.../iio:deviceX/events/in_anglvel_y_roc_rising_en
@@ -1129,6 +1130,7 @@ Description:
will get activated once in_voltage0_raw goes above 1200 and will become
deactivated again once the value falls below 1150.
+What: /sys/.../events/in_accel_roc_rising_value
What: /sys/.../events/in_accel_x_raw_roc_rising_value
What: /sys/.../events/in_accel_x_raw_roc_falling_value
What: /sys/.../events/in_accel_y_raw_roc_rising_value
@@ -1177,6 +1179,7 @@ Description:
What: /sys/.../events/in_accel_x_thresh_rising_period
What: /sys/.../events/in_accel_x_thresh_falling_period
+What: /sys/.../events/in_accel_roc_rising_period
What: /sys/.../events/in_accel_x_roc_rising_period
What: /sys/.../events/in_accel_x_roc_falling_period
What: /sys/.../events/in_accel_y_thresh_rising_period
@@ -1187,6 +1190,7 @@ What: /sys/.../events/in_accel_z_thresh_rising_period
What: /sys/.../events/in_accel_z_thresh_falling_period
What: /sys/.../events/in_accel_z_roc_rising_period
What: /sys/.../events/in_accel_z_roc_falling_period
+What: /sys/.../events/in_accel_mag_adaptive_rising_period
What: /sys/.../events/in_anglvel_x_thresh_rising_period
What: /sys/.../events/in_anglvel_x_thresh_falling_period
What: /sys/.../events/in_anglvel_x_roc_rising_period
@@ -1344,6 +1348,23 @@ Description:
number or direction is not specified, applies to all channels of
this type.
+What: /sys/.../iio:deviceX/events/in_accel_x_mag_adaptive_rising_en
+What: /sys/.../iio:deviceX/events/in_accel_y_mag_adaptive_rising_en
+What: /sys/.../iio:deviceX/events/in_accel_z_mag_adaptive_rising_en
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Similar to in_accel_x_thresh[_rising|_falling]_en, but here the
+ adaptive magnitude of the channel is compared to the threshold.
+
+What: /sys/.../events/in_accel_mag_adaptive_rising_value
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ The value to which the reference adaptive magnitude of the channel is
+ compared. If the axis is not specified, it applies to all channels
+ of this type.
+
What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_en
What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_rising_en
What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_falling_en
@@ -2386,3 +2407,22 @@ Description:
Value representing the user's attention to the system expressed
in units as percentage. This usually means if the user is
looking at the screen or not.
+
+What: /sys/.../events/in_accel_value_available
+KernelVersion: 6.18
+Contact: linux-iio@vger.kernel.org
+Description:
+ List of available acceleration threshold values that can be
+ configured for event generation. Units after application of
+ scale and offset are m/s^2. Expressed as:
+
+ - a range specified as "[min step max]"
+
+What: /sys/.../events/in_accel_period_available
+KernelVersion: 6.18
+Contact: linux-iio@vger.kernel.org
+Description:
+ List of available periods for accelerometer event detection in
+ seconds, expressed as:
+
+ - a range specified as "[min step max]"
--
2.51.0On Sat, 30 Aug 2025 08:58:57 -0300 Gustavo Silva <gustavograzs@gmail.com> wrote: > Add accelerometer and rate of change event-related sysfs attributes > exposed by the bmi270 driver. > > Signed-off-by: Gustavo Silva <gustavograzs@gmail.com> > --- > Documentation/ABI/testing/sysfs-bus-iio | 40 +++++++++++++++++++++++++ > 1 file changed, 40 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio > index 2fb2cea4b192..75a88f0dc533 100644 > --- a/Documentation/ABI/testing/sysfs-bus-iio > +++ b/Documentation/ABI/testing/sysfs-bus-iio > @@ -908,6 +908,7 @@ What: /sys/.../iio:deviceX/events/in_accel_y_roc_rising_en > What: /sys/.../iio:deviceX/events/in_accel_y_roc_falling_en > What: /sys/.../iio:deviceX/events/in_accel_z_roc_rising_en > What: /sys/.../iio:deviceX/events/in_accel_z_roc_falling_en > +What: /sys/.../iio:deviceX/events/in_accel_x&y&z_roc_rising_en > What: /sys/.../iio:deviceX/events/in_anglvel_x_roc_rising_en > What: /sys/.../iio:deviceX/events/in_anglvel_x_roc_falling_en > What: /sys/.../iio:deviceX/events/in_anglvel_y_roc_rising_en > @@ -1129,6 +1130,7 @@ Description: > will get activated once in_voltage0_raw goes above 1200 and will become > deactivated again once the value falls below 1150. > > +What: /sys/.../events/in_accel_roc_rising_value > What: /sys/.../events/in_accel_x_raw_roc_rising_value > What: /sys/.../events/in_accel_x_raw_roc_falling_value > What: /sys/.../events/in_accel_y_raw_roc_rising_value > @@ -1177,6 +1179,7 @@ Description: > > What: /sys/.../events/in_accel_x_thresh_rising_period > What: /sys/.../events/in_accel_x_thresh_falling_period > +What: /sys/.../events/in_accel_roc_rising_period > What: /sys/.../events/in_accel_x_roc_rising_period > What: /sys/.../events/in_accel_x_roc_falling_period > What: /sys/.../events/in_accel_y_thresh_rising_period > @@ -1187,6 +1190,7 @@ What: /sys/.../events/in_accel_z_thresh_rising_period > What: /sys/.../events/in_accel_z_thresh_falling_period > What: /sys/.../events/in_accel_z_roc_rising_period > What: /sys/.../events/in_accel_z_roc_falling_period > +What: /sys/.../events/in_accel_mag_adaptive_rising_period > What: /sys/.../events/in_anglvel_x_thresh_rising_period > What: /sys/.../events/in_anglvel_x_thresh_falling_period > What: /sys/.../events/in_anglvel_x_roc_rising_period > @@ -1344,6 +1348,23 @@ Description: > number or direction is not specified, applies to all channels of > this type. > > +What: /sys/.../iio:deviceX/events/in_accel_x_mag_adaptive_rising_en > +What: /sys/.../iio:deviceX/events/in_accel_y_mag_adaptive_rising_en > +What: /sys/.../iio:deviceX/events/in_accel_z_mag_adaptive_rising_en > +KernelVersion: 2.6.37 > +Contact: linux-iio@vger.kernel.org > +Description: > + Similar to in_accel_x_thresh[_rising|_falling]_en, but here the > + adaptive magnitude of the channel is compared to the threshold. That seems backwards. I was thinking of this as the magnitude of the channel is compared to an adaptive threshold. I'm not sure what 'adaptive magnitude of the channel' would mean. > + > +What: /sys/.../events/in_accel_mag_adaptive_rising_value I'm not sure this one needs it's own block. For the nearest equivalent which is _adaptive_rising_value (which is only documented for capacitive channels we just put it in the same block as the non _adaptive_ variant. > +KernelVersion: 2.6.37 > +Contact: linux-iio@vger.kernel.org > +Description: > + The value to which the reference adaptive magnitude of the channel is > + compared. If the axis is not specified, it applies to all channels > + of this type. > + > What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_en > What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_rising_en > What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_falling_en > @@ -2386,3 +2407,22 @@ Description: > Value representing the user's attention to the system expressed > in units as percentage. This usually means if the user is > looking at the screen or not. > + > +What: /sys/.../events/in_accel_value_available > +KernelVersion: 6.18 > +Contact: linux-iio@vger.kernel.org > +Description: > + List of available acceleration threshold values that can be > + configured for event generation. Units after application of > + scale and offset are m/s^2. Expressed as: > + This is generic. What sort of event does it apply to? Seems like it should be in_accel_mag_adaptive_value or something along those lines? Might also need in_acecl_mag_reference_value or even direction specific variants of each. Whilst the ABI does allow for a broader 'available' to cover for all channels for instance so this is sort of valid ABI, to me it just feels non intuitive for a user. Maybe just adding tot this document to say that this applies to all forms of event for in_accel channels on this device is sufficient. > + - a range specified as "[min step max]" > + > +What: /sys/.../events/in_accel_period_available This one feels more reasonable as the idea of all events sharing a period control is more likely than the values that are accepted being the same for all. > +KernelVersion: 6.18 > +Contact: linux-iio@vger.kernel.org > +Description: > + List of available periods for accelerometer event detection in > + seconds, expressed as: > + > + - a range specified as "[min step max]"
On Sat, Aug 30, 2025 at 2:58 PM Gustavo Silva <gustavograzs@gmail.com> wrote: > > Add accelerometer and rate of change event-related sysfs attributes > exposed by the bmi270 driver. Seems to me like the absent attributes that are already in the kernel, should be added in the separate patch. ... > +What: /sys/.../iio:deviceX/events/in_accel_x&y&z_roc_rising_en Out of curiosity, is it for real? I mean & (ampersand) in the sysfs attribute name? This is quite inconvenient for use in shells. -- With Best Regards, Andy Shevchenko
On Sat, 30 Aug 2025 15:49:50 +0300 Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Sat, Aug 30, 2025 at 2:58 PM Gustavo Silva <gustavograzs@gmail.com> wrote: > > > > Add accelerometer and rate of change event-related sysfs attributes > > exposed by the bmi270 driver. > > Seems to me like the absent attributes that are already in the kernel, > should be added in the separate patch. Agreed that would be ideal. > > ... > > > +What: /sys/.../iio:deviceX/events/in_accel_x&y&z_roc_rising_en > > Out of curiosity, is it for real? I mean & (ampersand) in the sysfs > attribute name? This is quite inconvenient for use in shells. Yup. Easy enough to escape... It's really wordy to express boolean relationships without using symbols. This has been in the ABI all the way back to the beginning I think. Jonathan >
On Sat, 30 Aug 2025 18:05:34 +0100 Jonathan Cameron <jic23@kernel.org> wrote: > On Sat, 30 Aug 2025 15:49:50 +0300 > Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > On Sat, Aug 30, 2025 at 2:58 PM Gustavo Silva <gustavograzs@gmail.com> wrote: > > > > > > Add accelerometer and rate of change event-related sysfs attributes > > > exposed by the bmi270 driver. > > > > Seems to me like the absent attributes that are already in the kernel, > > should be added in the separate patch. > Agreed that would be ideal. Actually what did you mean by absent attributes? This is documenting ABI that is part of the general 'scope' of the full IIO ABI but which hasn't turned up before in this particular combination (or possibly we missed updating docs when it did!) Whether it is worth separating out any we know are in another driver is an open question, but Gustavo hasn't called out any as being like that. It's possible that these are all surfacing for the first time in this driver. Jonathan > > > > ... > > > > > +What: /sys/.../iio:deviceX/events/in_accel_x&y&z_roc_rising_en > > > > Out of curiosity, is it for real? I mean & (ampersand) in the sysfs > > attribute name? This is quite inconvenient for use in shells. > > Yup. > > Easy enough to escape... > > It's really wordy to express boolean relationships without using symbols. > This has been in the ABI all the way back to the beginning I think. > > Jonathan > > > >
On Sat, Aug 30, 2025 at 8:09 PM Jonathan Cameron <jic23@kernel.org> wrote: > On Sat, 30 Aug 2025 18:05:34 +0100 > Jonathan Cameron <jic23@kernel.org> wrote: > > On Sat, 30 Aug 2025 15:49:50 +0300 > > Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > On Sat, Aug 30, 2025 at 2:58 PM Gustavo Silva <gustavograzs@gmail.com> wrote: > > > > > > > > Add accelerometer and rate of change event-related sysfs attributes > > > > exposed by the bmi270 driver. > > > > > > Seems to me like the absent attributes that are already in the kernel, > > > should be added in the separate patch. > > Agreed that would be ideal. > > Actually what did you mean by absent attributes? Absent in the documentation, but present in the code. That's what this patch adds mainly, no? > This is documenting ABI that is part of the general 'scope' of the full > IIO ABI but which hasn't turned up before in this particular combination > (or possibly we missed updating docs when it did!) > > Whether it is worth separating out any we know are in another driver is > an open question, but Gustavo hasn't called out any as being like that. > It's possible that these are all surfacing for the first time in this driver. Hmm... But if the code handles the attribute which is not documented, that needs to be fixed. -- With Best Regards, Andy Shevchenko
On Sat, 30 Aug 2025 22:58:17 +0300 Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Sat, Aug 30, 2025 at 8:09 PM Jonathan Cameron <jic23@kernel.org> wrote: > > On Sat, 30 Aug 2025 18:05:34 +0100 > > Jonathan Cameron <jic23@kernel.org> wrote: > > > On Sat, 30 Aug 2025 15:49:50 +0300 > > > Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > > On Sat, Aug 30, 2025 at 2:58 PM Gustavo Silva <gustavograzs@gmail.com> wrote: > > > > > > > > > > Add accelerometer and rate of change event-related sysfs attributes > > > > > exposed by the bmi270 driver. > > > > > > > > Seems to me like the absent attributes that are already in the kernel, > > > > should be added in the separate patch. > > > Agreed that would be ideal. > > > > Actually what did you mean by absent attributes? > > Absent in the documentation, but present in the code. That's what this > patch adds mainly, no? > > > This is documenting ABI that is part of the general 'scope' of the full > > IIO ABI but which hasn't turned up before in this particular combination > > (or possibly we missed updating docs when it did!) > > > > Whether it is worth separating out any we know are in another driver is > > an open question, but Gustavo hasn't called out any as being like that. > > It's possible that these are all surfacing for the first time in this driver. > > Hmm... But if the code handles the attribute which is not documented, > that needs to be fixed. > The core code handles a massive number of combinations that make no sense because the attributes are constructed from 5+ parameters, each with many values. So what matters here is whether a combination is in use, not whether it could be instantiate by a driver using standard IIO structures. Sometimes we miss things in reviews so gaps occur. Those absolutely should be fixed, but we shouldn't documents stuff on basis it 'might' be ABI in future. Jonathan
© 2016 - 2025 Red Hat, Inc.