Expand sensor_info struct and DTS bindings

[yperess]

Introduction

Some additional information about the sensor might come in handy both at compile time and at runtime. I'm proposing we add additional sensor attributes to the sensor-device.yaml which will allow developers to check capabilities of the sensor at compile time. Additionally a new Kconfig.sensor_info will be added to allow saving this information for runtime.

Problem description

In many cases, the runtime selection of the sensor configuration comes from another processor which may be making complex decisions based on the possibilities presented. For example, if the sensor supports 200Hz and 400Hz ODRs. Without knowing this, the host may request a value that's not directly supported (300Hz) which means that 400Hz is likely to be selected and the host will have to downsample. There's a slew of ramifications to this which might have been avoided by the host knowing that 300Hz isn't a viable option.

Proposed change

1. Add new entries to the sensor-device.yaml bindings to list out some additional sensor attribute values.
2. Add a new Kconfig.sensor_info which will allow saving these attributes to the sensor_info struct

Detailed RFC

Proposed change (Detailed)

types:
  type: array
  description: |
    List of sensor channel types. Example:
    <SENSOR_CHAN_ACCEL SENSOR_CHAN_GYRO>
odrs:
  type: array
  description: |
    List of sample rates in mHz. Example:
    <12500 25000 50000>
 ranges:
  type: array
  description: |
    List of ranges in milli SI units

It should already be possible to check statically if a value is found in a DTS array:

#define CHECK_FOR_VALUE_IDX(node_id, prop, idx, check_value) \
    (DT_PROP_BY_IDX(node_id, idx) == check_value)

#define CHECK_FOR_VALUE(node_id, field_name, check_value)
    DT_FOREACH_PROP_ELEM_SEP_VARGS(node_id, field_name,
                                   CHECK_FOR_VALUE_IDX, (+), check_value) == 1

#if CHECK_FOR_VALUE(DT_NODELABEL(node), my_field, 18)

// 18 was found

#endif

I haven't worked out what the equivalent min/max functions would look like, but that would be the next utility to provide.

The runtime changes would be simpler, based on the Kconfig we would either include the new fields in the sensor_info struct or not.

[yperess]

@MaureenHelm for comment soliciting

[MaureenHelm]

I had something like this in mind when I introduced sensor-device.yaml. This should be straightforward for sensors that only support one channel type, but combo sensors will need to define some properties on a channel-type or channel-group basis. For example, the ranges property would need to be different for accelerometer vs. gyroscope channels on a 6-axis device, and the odrs property might differ for a die temperature channel. Therefore I think we might need another layer to define these properties in one or more child-nodes of the sensor.

I agree that an application should know if the sample rate configured doesn't equal the sample rate requested. I used to try to enforce sensor drivers returning an error code instead of rounding up to the next supported sample rate, but there were too many reviews and I couldn't keep up with it.

[teburd]

The sensor channels is limited here by the current enum sensor_channel, this leaves a lot to be desired. It would be great to allow structured data be available for each sensor definition, perhaps allow for named aliases (could be static const defines of a channel spec), metadata about a channel (e.g. its a light reading, with a custom frequency, and index N, with frequency f)

See #63830

[henrikbrixandersen]

The sensor channels is limited here by the current enum sensor_channel, this leaves a lot to be desired.

Agreed. We need to ensure that this will work just as well for custom, out-of-tree sensor channels.