Initializing the regmap_ranges using direct assignment to the range_min
and range_max members is slightly verbose. We can make it a tad cleaner
when using the regmap_reg_range() macro.
Clean up the code using regmap_reg_range() when initializing the
regmap_range structure.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Correct and add to adis.h to resolve all kernel-doc warnings:
- add a missing struct member description
- change one non-kernel-doc comment to use /* instead of /**
- correct function parameter @value to @val (7 locations)
- add function return value comments (13 locations)
Warning: include/linux/iio/imu/adis.h:97 struct member 'has_fifo'
not described in 'adis_data'
Warning: include/linux/iio/imu/adis.h:139 Incorrect use of kernel-doc
format: * The state_lock is meant to be used during operations that
require
Warning: include/linux/iio/imu/adis.h:158 struct member '"__adis_"'
not described in 'adis'
Warning: include/linux/iio/imu/adis.h:264 function parameter 'val'
not described in 'adis_write_reg'
Warning: include/linux/iio/imu/adis.h:371 No description found for
return value of 'adis_update_bits_base'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add driver for Aosong adp810 differential pressure and temperature sensor.
This sensor provides an I2C interface for reading data.
Calculate CRC of the data received using standard crc8 library to verify
data integrity.
Tested on TI am62x sk board with sensor connected at i2c-2.
Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add bindings for adp810 differential pressure and temperature
sensor. This sensor communicates over I2C with CRC support and
can measure pressure in the range -500 to 500Pa and temperature
in the range -40 to +85 degree celsius.
Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The intention here was clearly to return -ENODEV but the return statement
was missing. It would result in an off by one read in i3c_chip_info[] on
the next line. Add the return statement.
Fixes: 1bef24e900 ("iio: imu: inv_icm45600: add I3C driver for inv_icm45600 driver")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The SARADC of the RK3506 is similar to the one found in the RK3528
in terms of number of channels and the other implementation details.
So add a variant compatible for it, that reflects this fact.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for AD4087 14-bit SAR ADC. The AD4087 differs from
AD4080 in resolution (14-bit vs 20-bit) and LVDS CNV clock count
maximum (1 vs 7).
Changes:
- Add AD4087_CHIP_ID definition (0x0057)
- Create ad4087_channel with 14-bit resolution and 16-bit storage
- Add ad4087_chip_info with lvds_cnv_clk_cnt_max = 1
- Register AD4087 in device ID and OF match tables
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add device tree binding support for the AD4087 14-bit SAR ADC.
Add adi,ad4087 to the compatible enum.
A fallback compatible string to adi,ad4080 is not appropriate as the
AD4087 has different resolution (14-bit vs 20-bit) and LVDS CNV clock
count maximum (1 vs 7), requiring different driver configuration.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for AD4086 14-bit SAR ADC. The AD4086 differs from
AD4080 in resolution (14-bit vs 20-bit) and LVDS CNV clock count
maximum (4 vs 7).
Changes:
- Add AD4086_CHIP_ID definition (0x0056)
- Create ad4086_channel with 14-bit resolution and 16-bit storage
- Add ad4086_chip_info with lvds_cnv_clk_cnt_max = 4
- Register AD4086 in device ID and OF match tables
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add device tree binding support for the AD4086 14-bit SAR ADC.
Add adi,ad4086 to the compatible enum.
A fallback compatible string to adi,ad4080 is not appropriate as the
AD4086 has different resolution (14-bit vs 20-bit) and LVDS CNV clock
count maximum (4 vs 7), requiring different driver configuration.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for AD4083 16-bit SAR ADC. The AD4083 differs from
AD4080 in resolution (16-bit vs 20-bit) and LVDS CNV clock count
maximum (5 vs 7).
Changes:
- Add AD4083_CHIP_ID definition (0x0053)
- Create ad4083_channel with 16-bit resolution and storage
- Add ad4083_chip_info with lvds_cnv_clk_cnt_max = 5
- Register AD4083 in device ID and OF match tables
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add device tree binding support for the AD4083 16-bit SAR ADC.
Add adi,ad4083 to the compatible enum.
A fallback compatible string to adi,ad4080 is not appropriate as the
AD4083 has different resolution (16-bit vs 20-bit) and LVDS CNV clock
count maximum (5 vs 7), requiring different driver configuration.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add the iio driver for bosch imu smi330. The smi330 is a combined
three axis angular rate and three axis acceleration sensor.
Signed-off-by: Jianping Shen <Jianping.Shen@de.bosch.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fix multiple warnings in enum vadc_scale_fn_type by adding a leading
'@' to the kernel-doc descriptions.
Fixed 14 warnings in this one enum, such as:
Warning: include/linux/iio/adc/qcom-vadc-common.h:123 Enum value
'SCALE_DEFAULT' not described in enum 'vadc_scale_fn_type'
Warning: ../include/linux/iio/adc/qcom-vadc-common.h:123 Enum value
'SCALE_THERM_100K_PULLUP' not described in enum 'vadc_scale_fn_type'
Warning: ../include/linux/iio/adc/qcom-vadc-common.h:123 Enum value
'SCALE_PMIC_THERM' not described in enum 'vadc_scale_fn_type'
Also prevent the warning on SCALE_HW_CALIB_INVALID by marking it
"private:" so that kernel-doc notation is not needed for it.
This leaves only one warning here, which I don't know the
appropriate description of:
qcom-vadc-common.h:125: warning: Enum value
'SCALE_HW_CALIB_PMIC_THERM_PM7' not described in enum 'vadc_scale_fn_type'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The MAX14001/MAX14002 is configurable, isolated 10-bit ADCs for multi-range
binary inputs. In addition to ADC readings, the MAX14001/MAX14002 offers
more features, like a binary comparator, a filtered reading that can
provide the average of the last 2, 4, or 8 ADC readings, and an inrush
comparator that triggers the inrush current. There is also a fault feature
that can diagnose seven possible fault conditions. And an option to select
an external or internal ADC voltage reference.
MAX14001/MAX14002 features implemented so far:
- Raw ADC reading.
- MV fault disable.
- Selection of external or internal ADC voltage reference, depending on
whether it is declared in the device tree.
Co-developed-by: Kim Seer Paller <kimseer.paller@analog.com>
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Signed-off-by: Marilene Andrade Garcia <marilene.agarcia@gmail.com>
Tested-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add device-tree documentation for MAX14001/MAX14002 ADCs.
The MAX14001/MAX14002 are isolated, single-channel analog-to-digital
converters with programmable voltage comparators and inrush current
control optimized for configurable binary input applications.
They share the same features, but in the MAX14001 the inrush trigger
threshold, current magnitude, and current duration are all programmable,
whereas in the MAX14002 these parameters are fixed.
Co-developed-by: Kim Seer Paller <kimseer.paller@analog.com>
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Signed-off-by: Marilene Andrade Garcia <marilene.agarcia@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The rate at which accelerometer or gyroscope sensor samples are fed
to the hardware FIFO (batch data rate, or BDR) does not have to
coincide with the sensor sampling frequency (output data rate, or
ODR); the only requirement is for the BDR to not be greater than
the ODR. Having a BDR lower than the ODR is useful in cases where
an application requires a high sampling rate for accurate detection
of motion events (e.g. wakeup events), but wants to read sensor
sample values from the hardware FIFO at a lower data rate (e.g. to
minimize the amount of I2C or SPI traffic and the rate of periodic
interrupts).
To support the above use case, add a sampling_frequency sysfs
attribute to the buffer directory of st_lsm6dsx IIO devices, which
controls the BDR for a given sensor independently from the "main"
sampling_frequency attribute (which controls the ODR); introduce a
new `hwfifo_odr_mHz` field in struct st_lsm6dsx_sensor to keep
track of the current BDR value, and use this field instead of the
`odr` field in the code that deals with the FIFO data rate. In the
sensor hub driver, make the hwfifo_odr_mHz value always mirror the
odr value, since there is no separate configuration setting to
control the BDR for data produced by the sensor hub functionality.
For backwards compatibility, set the buffer frequency equal to the
main frequency whenever the latter is updated via sysfs; if
userspace wants a different buffer frequency, it has to write to
the relevant sysfs attribute after any writes to the main frequency
attribute.
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The `odr` field in struct st_lsm6dsx_sensor contains a data rate
value expressed in mHz, not in Hz.
Fixes: f8710f0357 ("iio: imu: st_lsm6dsx: express odr in mHZ")
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Remove errno.h include from bma220_i2c.c since error codes are generated
within bma220_core.c instead.
Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
FIELD_PREP() checks that a value fits into the available bitfield, add a
check for step_avg to fix gcc complains.
which gcc complains about:
drivers/iio/adc/ti_am335x_adc.c: In function 'tiadc_step_config':
include/linux/compiler_types.h:572:38: error: call to
'__compiletime_assert_491' declared with attribute error: FIELD_PREP: value
too large for the field include/linux/mfd/ti_am335x_tscadc.h:58:29: note:
in expansion of macro 'FIELD_PREP'
#define STEPCONFIG_AVG(val) FIELD_PREP(GENMASK(4, 2), (val))
^~~~~~~~~~
drivers/iio/adc/ti_am335x_adc.c:127:17: note: in expansion of macro 'STEPCONFIG_AVG'
stepconfig = STEPCONFIG_AVG(ffs(adc_dev->step_avg[i]) - 1)
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202510102117.Jqxrw1vF-lkp@intel.com/
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Append additional information to existing comments in the generic
interrupt configuration code to provide more context.
Signed-off-by: Akshay Jindal <akshayaj.lkd@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The function activity_event_en() configures the generic interrupts
GEN1 and GEN2, which are used for activity and inactivity detection
as per the datasheet. The existing name is misleading, since the
device also provides activity change and activity recognition
interrupts. Activity change interrupt is not supported yet whereas
Activity recognition interrupt is configured in a different function.
Rename activity_event_en() to generic_event_en() to better reflect its
actual purpose.
No functional changes intended.
Signed-off-by: Akshay Jindal <akshayaj.lkd@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
set_* functions involve left shift of param values into respective
register fields before writing to register. Similarly get_* functions
involve right shift to extract values from the respective bit fields.
Replace these explicit shifting statements with standard kernel style
macros FIELD_GET() and FIELD_PREP().
Signed-off-by: Akshay Jindal <akshayaj.lkd@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Introduce formula-based macros to compute GEN INTR configuration register
addresses from the interrupt number and register index. This reduces the
need for 22 explicit register macros to three base definitions.
Add a centralized lookup table keyed by IIO event direction and replace
get_gen_config_reg() with a helper integrated with this table.
Apply these changes across the affected callbacks to ensure consistent
access to generic interrupt registers.
No functional changes are intended.
Signed-off-by: Akshay Jindal <akshayaj.lkd@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add macros and enums for configuration values used in generic event
handling for activity and inactivity detection. Replace hard-coded
values in activity_event_en() with the new definitions to make the
configuration explicit.
No functional changes are intended.
Signed-off-by: Akshay Jindal <akshayaj.lkd@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reorganize register and field macros to improve consistency with the
datasheet and naming style:
- Move field macros next to their corresponding register macros
- Reorder register macros to follow address order from the datasheet
- Rename field macros to include the register name in the macro name
- Add a _REG suffix to register macros where missing
- Add INT_STAT register fields corresponding to used INT_CONFIG fields
No functional changes are intended.
Signed-off-by: Akshay Jindal <akshayaj.lkd@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The required LED pulse width depends on board-specific optical and
mechanical design, which affects measurement accuracy and power use.
Making it configurable via Device Tree allows each platform to define
an appropriate value instead of relying on a hardcoded default.
If unspecified, the driver defaults to 1600 us for backward compatibility.
Tested on: Raspberry Pi 3B + MAX30100 breakout board.
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: Shrikant Raskar <raskar.shree97@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The LED pulse width on the MAX30100 sensor determines how long the
IR/Red LEDs are driven during each sample, directly affecting the
emitted optical energy and hence the received signal amplitude.
This parameter is highly dependent on the mechanical and optical
integration of the sensor, such as:
- The type and thickness of the optical window or lens covering
the sensor.
- The distance between the LED and photodiode.
- The reflectivity of the target surface.
For example:
- A smartwatch or wearable ring with a thin glass window can operate
with shorter pulses (200-400 us) to save power.
- A medical-grade pulse oximeter or sensor mounted behind a thicker
protective layer may require longer pulses (800-1600 us) for
reliable signal amplitude.
Because this configuration is determined by hardware design rather than
by runtime conditions, it is appropriate to describe it in the DT.
If not specified, the driver defaults to 1600 us to maintain
existing behavior.
Tested on: Raspberry Pi 3B + MAX30100 breakout board.
Signed-off-by: Shrikant Raskar <raskar.shree97@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The pinout of all the supported chips in this binding have two interrupt
pins. Document the second one, too, even though the Linux driver
currently does not support the second interrupt. Boards may have it
wired nonetheless. While here, drop the dependency of interrupt-names
which is already described in the core.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The error code returned from devm_iio_trigger_register() inturn
iio_trigger_register() can be other than -ENOMEM. Hence return the
same value as it was returned from the function call.
This change makes devm_iio_trigger_register() handling uniform with
other iio drivers.
Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for AD4081 20-bit SAR ADC. The AD4081 has the same
resolution as AD4080 (20-bit) but differs in LVDS CNV clock count
maximum (2 vs 7).
Changes:
- Add AD4081_CHIP_ID definition (0x0051)
- Create ad4081_channel with 20-bit resolution and 32-bit storage
- Add ad4081_chip_info with lvds_cnv_clk_cnt_max = 2
- Register AD4081 in device ID and OF match tables
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add device tree binding support for the AD4081 20-bit SAR ADC.
Add adi,ad4081 to the compatible enum.
A fallback compatible string to adi,ad4080 is not appropriate as the
AD4081 has a different LVDS CNV clock count maximum (2 vs 7), requiring
different driver configuration.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for AD4084 16-bit SAR ADC. The AD4084 differs from
AD4080 in resolution (16-bit vs 20-bit) and LVDS CNV clock count
maximum (2 vs 7).
Changes:
- Add AD4084_CHIP_ID definition (0x0054)
- Create ad4084_channel with 16-bit resolution and storage
- Add ad4084_chip_info with appropriate configuration
- Register AD4084 in device ID and OF match tables
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add device tree binding support for the AD4084 16-bit SAR ADC.
Add adi,ad4084 to the compatible enum.
A fallback compatible string to adi,ad4080 is not appropriate as the
AD4084 has different resolution (16-bit vs 20-bit) and LVDS CNV clock
count maximum (2 vs 7), requiring different driver configuration.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Refactor the ad4080 driver to support multiple ADC variants with
different resolution bits and LVDS CNV clock count maximums.
Changes:
- Add lvds_cnv_clk_cnt_max field to chip_info structure
- Create AD4080_CHANNEL_DEFINE macro for variable resolution/storage bits
- Make LVDS CNV clock count configurable per chip variant
- Use chip_info->product_id for chip identification comparison
This prepares the infrastructure for adding support for additional
ADC parts with different specifications while maintaining backward
compatibility with existing AD4080 functionality.
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fix AD4080 chip identification by using the correct 16-bit product ID
(0x0050) instead of GENMASK(2, 0). Update the chip reading logic to
use regmap_bulk_read to read both PRODUCT_ID_L and PRODUCT_ID_H
registers and combine them into a 16-bit value.
The original implementation was incorrectly reading only 3 bits,
which would not correctly identify the AD4080 chip.
Fixes: 6b31ba1811 ("iio: adc: ad4080: add driver support")
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add IIO device for accelerometer sensor
with data polling interface and FIFO parsing.
Attributes: raw, scale, sampling_frequency, calibbias.
Temperature is available as a processed channel.
Signed-off-by: Remi Buisson <remi.buisson@tdk.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add IIO device for gyroscope sensor
with data polling interface and FIFO parsing.
Attributes: raw, scale, sampling_frequency, calibbias.
Temperature is available as a processed channel.
Signed-off-by: Remi Buisson <remi.buisson@tdk.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add FIFO control functions.
Support hwfifo watermark by multiplexing gyro and accel settings.
Support hwfifo flush.
Signed-off-by: Remi Buisson <remi.buisson@tdk.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Core component of a new driver for InvenSense ICM-45600 devices.
It includes registers definition, main probe/setup, and device
utility functions.
ICM-456xx devices are latest generation of 6-axis IMU,
gyroscope+accelerometer and temperature sensor. This device
includes a 8K FIFO, supports I2C/I3C/SPI, and provides
intelligent motion features like pedometer, tilt detection,
and tap detection.
Signed-off-by: Remi Buisson <remi.buisson@tdk.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Document the ICM-45600 devices devicetree bindings.
Specific variants of the device are defined because of their
differences in terms of FSR or advanced features like eDMP.
Signed-off-by: Remi Buisson <remi.buisson@tdk.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The DPS310 is a barometric pressure and temperature sensor with
an I2C interface. Remove it from trivial-devices.yaml and add its
own documentation to allow for consumers of this device such as
the iio/hwmon bridge.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
