Rename the static `ds4424_info` structure to `ds4424_iio_info`.
The previous name was generic and could be confused with chip-specific
data structures (like the upcoming `ds4424_chip_info`). The new name
explicitly indicates that this structure holds the IIO framework
callbacks.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sort the header inclusions alphabetically. This improves readability and
simplifies adding new includes in the future.
Group subsystem-specific headers (linux/iio/*) separately at the end
to clarify subsystem context.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Replace pr_err() with dev_err_ratelimited() in the RAW read path to avoid
log spam on repeated I2C failures and to include the device context.
Use %pe to print errno names for faster debugging. Use the parent
device context to identify the physical hardware causing the error.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Refactor the raw access logic to use standard GENMASK() and BIT()
macros. Use abs() for magnitude calculation to simplify the logic and
make the data flow clearer.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use the proper kernel-doc format and struct member names to avoid
kernel-doc warnings:
Warning: include/linux/iio/common/st_sensors.h:184 struct member 'int1'
not described in 'st_sensor_data_ready_irq'
Warning: ../include/linux/iio/common/st_sensors.h:184 struct member 'int2'
not described in 'st_sensor_data_ready_irq'
Warning: ../include/linux/iio/common/st_sensors.h:184 struct member
'stat_drdy' not described in 'st_sensor_data_ready_irq'
Warning: ../include/linux/iio/common/st_sensors.h:184 struct member 'ig1'
not described in 'st_sensor_data_ready_irq'
Warning: ../include/linux/iio/common/st_sensors.h:219 struct member
'num_ch' not described in 'st_sensor_settings'
Warning: ../include/linux/iio/common/st_sensors.h:263 struct member
'num_data_channels' not described in 'st_sensor_data'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Introduce a local struct device variable in ad9523_probe() to simplify
subsequent conversions and improve code readability.
Split pdata declaration and assignment since the result is validated
immediately after.
No functional change.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use dev_err_probe() instead of dev_err() in the probe path to ensure
proper handling of deferred probing and to simplify error handling.
Also fix the format specifier for vco_freq_hz from %lld to %llu since
it is u64 (unsigned), and add missing newline to the error message.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Introduce a local struct device variable in admv4420_probe() to
simplify subsequent conversions and improve code readability.
No functional change.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use iio_push_to_buffers_with_ts_unaligned() to avoid unaligned access
when writing the timestamp in the rx_buf.
The previous implementation would have been fine on architectures that
support 4-byte alignment of 64-bit integers but could cause issues on
architectures that require 8-byte alignment.
Fixes: 902c4b2446 ("iio: adc: New driver for TI ADS7950 chips")
Signed-off-by: David Lechner <dlechner@baylibre.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Replace the per-call kmalloc() scratch buffer with the existing
buffer_data[] field present in struct st_sensor_data. The existing buffer
is DMA-aligned and sufficiently sized for all channel widths, so using it
avoids unnecessary dynamic memory allocation on each read.
This simplifies the code, removes redundant allocation and cleanup.
No functional change intended.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The calibration divisor is not directly specified in the datasheet, but can be calculated:
I = Current_LSB * Current
Current = ShuntVoltage * CAL / calibration_divisor
CAL = 0.00512 / (Current_LSB * Rshunt)
ShuntVoltage = Vshunt / ShuntVoltage_LSB
=> I = (0.00512 / (calibration_divisor*ShuntVoltage_LSB)) * (Vshunt / Rshunt)
Ohm's law, I = Vshunt / Rshunt
=> 0.00512 / (calibration_divisor*ShuntVoltage_LSB) = 1
ShuntVoltage_LSB = 2.5 uV = 0.0000025 V
=> calibration_divisor = 2048
Signed-off-by: Chuang Zhu <git@chuang.cz>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Remove setting scan.chan[3] to zero. Since commit 433b99e922 ("iio:
light: as73211: Ensure buffer holes are zeroed"), the entire scan struct
is zeroed before being filled with data, so this is redundant.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fix incorrect spelling from degredation to degradation and fixed
up some missing spaces prior to */
Signed-off-by: Shi Hao <i.shihao.999@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use digitize instead of digitalize, which is the correct technical term,
and add an article for clarity.
Signed-off-by: Shi Hao <i.shihao.999@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
For controllers with battery sensing capability (AST2600/AST2700), the
last channel uses a different circuit design optimized for battery
voltage measurement. This channel should not be enabled by default
along with other channels to avoid potential interference and power
efficiency issues.
This ensures optimal power efficiency for normal ADC operations while
maintaining full functionality when battery sensing is needed.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ADC stabilization delays in compensation mode and battery sensing
mode do not require atomic context. Using mdelay() here results in
unnecessary busy waiting.
Replace mdelay(1) with fsleep(1000) to allow the scheduler to run other
tasks while waiting for the ADC to stabilize.
Also fix a minor typo in the comment ("adc" -> "ADC").
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add helpers to generate channel masks and enable multiple ADC channels
according to the device model's channel count.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Defines a constant for the battery sensing channel, typically the last
channel of the ADC. Clarifies channel usage and improves code
readability.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for the Linear Technology LTC2654 quad DAC family.
The LTC2654 is a 4-channel, 16-/12-bit DAC with SPI interface,
sharing the same 24-bit SPI protocol as the existing LTC2632/
LTC2634/LTC2636 devices supported by this driver.
The 12-bit variants of LTC2654 reuse existing LTC2634 chip_info
structs as they are register-compatible.
Add support for the following variants:
- LTC2654L-16: 16-bit, 2.5V internal reference
- LTC2654L-12: 12-bit, 2.5V internal reference
- LTC2654H-16: 16-bit, 4.096V internal reference
- LTC2654H-12: 12-bit, 4.096V internal reference
Signed-off-by: David Marinovic <david.marinovic@pupin.rs>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add compatible strings for the LTC2654 quad-channel DAC family.
The LTC2654 devices are 4-channel, 16-/12-bit DACs with an internal
reference and SPI interface. They use the same 24-bit SPI command
format as the LTC2632/2634/2636 family.
The 16-bit variants (LTC2654-L16 and LTC2654-H16) require new
compatible strings, as no existing compatibles support 16-bit
resolution.
The 12-bit variants (LTC2654-L12 and LTC2654-H12) are register-
compatible with LTC2634-L12 and LTC2634-H12 respectively, and can
use them as fallback compatibles.
Signed-off-by: David Marinovic <david.marinovic@pupin.rs>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Remove the ltc2632_chip_info_tbl[] array and related
ltc2632_supported_device_ids enum used for looking up chip-specific
information. Instead, use separate static const struct
ltc2632_chip_info objects for each supported chip variant.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: David Marinovic <david.marinovic@pupin.rs>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Replace sprintf() with sysfs_emit() in sysfs attribute show functions.
sysfs_emit() is the preferred API for sysfs callbacks as it is aware
of the PAGE_SIZE buffer limit.
Also simplify the wavetype_available show functions by removing
the intermediate string variable and returning directly from each
branch.
Signed-off-by: Gabriel Rondon <grondon@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Replace sprintf() with sysfs_emit() in all sysfs attribute show
functions. sysfs_emit() is the preferred API for sysfs callbacks as
it is aware of the PAGE_SIZE buffer limit.
Also remove the unnecessary (int) cast in ad5933_show_frequency()
and use the correct format specifier %llu for the unsigned long long
freqreg variable.
Signed-off-by: Gabriel Rondon <grondon@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The data->near_level variable is already assigned 0 during
devm_kzalloc(), therefore checking if the property is present and then
assigning it 0 is redundant. Remove the check for device tree property
and let it fail silently if it is missing or invalid.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
After moving data->client and client->dev into variables of their own,
replace all instances of data->client and client->dev being used in
vcnl4200_init() and vcnl4000_probe() by the said variables to reduce
clutter.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The error code is available in the log after return. In our case,
attaching a triggered buffer can only fail if we are out of memory, as
no other buffer is being attached. Remove duplicate error messages to
reduce noise in dmesg.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Given both vcnl4000_init() and vcnl4200_init() end with
dev->chip_spec->set_power_state(), they can be called once from the
probe to enable the sensors. Move the set_power_state function from init
and call it after init function in probe.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Convert __devm_iio_backend_fwnode_get() to use the __free(fwnode_handle)
cleanup attribute for the fwnode_back variable, removing the need for
manual fwnode_handle_put() calls. Move the declaration closer to its
first use, narrowing its scope.
No functional change.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
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 support for the Analog Devices ADXL371, a +-200g 3-axis MEMS
accelerometer sharing the same register map as the ADXL372 but with
different ODR values (320/640/1280/2560/5120 Hz vs 400/800/1600/3200/
6400 Hz), different bandwidth values, and different timer scale
factors for activity/inactivity detection.
Due to a silicon anomaly (er001) causing FIFO data misalignment on
all current ADXL371 silicon, FIFO and triggered buffer support is
disabled for the ADXL371 - only direct mode reads are supported.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Extract the triggered buffer, trigger allocation, and IRQ request
logic from adxl372_probe() into a dedicated adxl372_buffer_setup()
helper. This reduces the probe function complexity and prepares for
conditionally disabling buffer support on device variants with
known FIFO issues.
No functional change intended.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add the adi,adxl371 compatible string to the ADXL372 binding. The
ADXL371 is a +-200g 3-axis MEMS accelerometer nearly identical to
the ADXL372 in register layout, differing only in ODR/bandwidth
values, timer scale factors, and a silicon anomaly affecting FIFO
operation.
Update the title and description to reflect both devices.
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>
