Javier Carrasco [Sun, 29 Sep 2024 20:38:46 +0000 (22:38 +0200)]
iio: light: veml6070: add action for i2c_unregister_device
Simplify the code by adding an action to call i2c_unregister_device(),
which removes the need for a 'fail' label, gotos to it, and an explicit
call in veml6070_remove().
Javier Carrasco [Thu, 26 Sep 2024 16:08:40 +0000 (18:08 +0200)]
iio: adc: ad5755: use scoped device_for_each_child_node()
Switch to device_for_each_child_node_scoped() to simplify the code by
removing the need for calls to fwnode_handle_put() in the error path, in
this particular case dropping the jump to error_out as well.
This prevents possible memory leaks if new error paths are added without
the required call to fwnode_handle_put().
iio: adc: ti-ads1119: Drop explicit initialization of struct i2c_device_id::driver_data to 0
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
iio: light: ltr390: Add interrupt persistance support
Added support to configure the threshold interrupt persistance value by
providing IIO_EV_INFO_PERIOD attribute. The value written to the
attribute should be in miliseconds and should be greater than the
sampling rate of the sensor.
iio: light: ltr390: Interrupts and threshold event support
Added support for threshold events for both the ALS and UVI channels.
The events are reported when the threshold interrupt is triggered. Both
rising and falling threshold types are supported.
Added support for suspend and resume PM ops.
We suspend the sensor by clearing the ALS_UVS_EN bit in the MAIN CONTROL
register. And we resume it by setting that bit.
Alexandru Ardelean [Thu, 19 Sep 2024 13:04:43 +0000 (16:04 +0300)]
iio: adc: ad7606: add support for AD7606C-{16,18} parts
The AD7606C-16 and AD7606C-18 are pretty similar with the AD7606B.
The main difference between AD7606C-16 & AD7606C-18 is the precision in
bits (16 vs 18).
Because of that, some scales need to be defined for the 18-bit variants, as
they need to be computed against 2**18 (vs 2**16 for the 16 bit-variants).
Because the AD7606C-16,18 also supports bipolar & differential channels,
for SW-mode, the default range of 10 V or ±10V should be set at probe.
On reset, the default range (in the registers) is set to value 0x3 which
corresponds to '±10 V single-ended range', regardless of bipolar or
differential configuration.
Aside from the scale/ranges, the AD7606C-16 is similar to the AD7606B.
The AD7606C-18 variant offers 18-bit precision. Because of this, the
requirement to use this chip is that the SPI controller supports padding
of 18-bit sequences to 32-bit arrays.
Alexandru Ardelean [Thu, 19 Sep 2024 13:04:42 +0000 (16:04 +0300)]
dt-bindings: iio: adc: add docs for AD7606C-{16,18} parts
The driver will support the AD7606C-16 and AD7606C-18.
This change adds the compatible strings for these devices.
The AD7606C-16,18 channels also support these (individually configurable)
types of channels:
- bipolar single-ended
- unipolar single-ended
- bipolar differential
Alexandru Ardelean [Thu, 19 Sep 2024 13:04:41 +0000 (16:04 +0300)]
dt-bindings: iio: adc: document diff-channels corner case for some ADCs
Some ADCs have channels with negative and positive inputs, which can be
used to measure differential voltage levels. These inputs/pins are
dedicated (to the given channel) and cannot be muxed as with other ADCs.
For those types of setups, the 'diff-channels' property can be specified to
be used with the channel number (or reg property) for both negative and
positive inputs/pins.
Alexandru Ardelean [Thu, 19 Sep 2024 13:04:40 +0000 (16:04 +0300)]
iio: adc: ad7606: rework available attributes for SW channels
For SW mode, the oversampling and scales attributes are always present.
So, they can be implemented via a 'read_avail' hook in iio_info.
For HW mode, it's a bit tricky, as these attributes get assigned based on
GPIO definitions.
So, for SW mode, we define a separate AD7606_SW_CHANNEL() macro, and use
that for the SW channels.
And 'ad7606_info_os_range_and_debug' can be renamed to
'ad7606_info_sw_mode' as it is only used for SW mode.
For the 'read_avail' hook, we'll need to allocate the SW scales, so that
they are just returned userspace without any extra processing.
The allocation will happen when then ad7606_state struct is allocated.
The oversampling available parameters don't need any extra processing; they
can just be passed back to userspace (as they are).
Alexandru Ardelean [Thu, 19 Sep 2024 13:04:39 +0000 (16:04 +0300)]
iio: adc: ad7606: wrap channel ranges & scales into struct
With the addition of AD7606C-16,18 which have differential & bipolar
channels (and ranges), which can vary from channel to channel, we'll need
to keep more information about each channel range.
To do that, we'll add a 'struct ad7606_chan_scale' type to hold just
configuration for each channel.
This includes the scales per channel (which can be different with AD7606C-16,18), as well as the range for each channel.
This driver was already keeping the range value for each channel before,
and since this is couple with the scales, it also makes sense to put them
in the same struct.
Alexandru Ardelean [Thu, 19 Sep 2024 13:04:38 +0000 (16:04 +0300)]
iio: adc: ad7606: move scale_setup as function pointer on chip-info
Up until now, all ADCs were 16-bit precision.
With the addition of the AD7606C some things will change. For one thing,
we'll need to setup available-scales for each channel. Also for the 18-bit
precision variants, the scales will be different.
This change adds a function-pointer to the chip-info struct to be able to
set this up (differently) for the new parts. For the current parts, the
scales are the same (for all parts) between HW and SW modes.
Also creating a 'ad7606_sw_mode_setup()' function that must be called
before the scale_setup callback. This is needed in case SW mode is enabled
for some ADCs.
Alexandru Ardelean [Thu, 19 Sep 2024 13:04:37 +0000 (16:04 +0300)]
iio: adc: ad7606: move 'val' pointer to ad7606_scan_direct()
The ad7606_scan_direct() function returns 'int', which is fine for 16-bit
samples.
But when going to 18-bit samples, these need to be implemented as 32-bit
(or int) type.
In that case when getting samples (which can be negative), we'd get random
error codes.
So, the easiest thing is to just move the 'val' pointer to
'ad7606_scan_direct()'. This doesn't qualify as a fix, it's just a
preparation for 18-bit ADCs (of the AD7606 family).
Neil Armstrong [Wed, 11 Sep 2024 15:29:53 +0000 (17:29 +0200)]
dt-bindings: iio: adc: amlogic,meson-saradc: also allow meson8-saradc to have amlogic,hhi-sysctrl property
The SARADC on the Amlogic Meson8 SoC also requires the amlogic,hhi-sysctrl,
property, document it by adding the amlogic,meson8-saradc compatible in the
adequate allOf:if:compatible:contains:enums along meson8b and meson8m2.
The AD8460 is a “bits in, power out” high voltage, high-power,
high-speed driver optimized for large output current (up to ±1 A)
and high slew rate (up to ±1800 V/μs) at high voltage (up to ±40 V)
into capacitive loads.
A digital engine implements user-configurable features: modes for
digital input, programmable supply current, and fault monitoring
and programmable protection settings for output current,
output voltage, and junction temperature. The AD8460 operates on
high voltage dual supplies up to ±55 V and a single low voltage
supply of 5 V.
Andy Shevchenko [Wed, 11 Sep 2024 21:31:10 +0000 (00:31 +0300)]
iio: imu: kmx61: Drop most likely fake ACPI ID
The commit in question does not proove that ACPI ID exists.
Quite likely it was a cargo cult addition while doint that
for DT-based enumeration. Drop most likely fake ACPI ID.
Googling for KMX61021L gives no useful results in regard to DSDT.
Moreover, the official vendor ID in the registry for Kionix is KIOX.
iio: light: al3010: Fix an error handling path in al3010_probe()
If i2c_smbus_write_byte_data() fails in al3010_init(),
al3010_set_pwr(false) is not called.
In order to avoid such a situation, move the devm_add_action_or_reset()
witch calls al3010_set_pwr(false) right after a successful
al3010_set_pwr(true).
iio: proximity: vl53l0x-i2c: Added continuous mode support
The continuous mode of the sensor is enabled in the buffer_postenable.
Replaced the original irq handler with a threaded irq handler to perform
i2c reads during continuous mode.
The continuous mode is disabled by disabling the buffer.
Added a trigger for this device to be used for continuous mode.
Alex Lanzano [Thu, 12 Sep 2024 21:07:19 +0000 (17:07 -0400)]
iio: imu: Add i2c driver for bmi270 imu
Add initial i2c support for the Bosch BMI270 6-axis IMU.
Provides raw read access to acceleration and angle velocity measurements
via iio channels. Device configuration requires firmware provided by
Bosch and is requested and load from userspace.
Antoni Pokusinski [Sun, 8 Sep 2024 17:21:53 +0000 (19:21 +0200)]
iio: temperature: tmp006: add triggered buffer support
Add support for continuous data capture using triggered buffers for the
tmp006 sensor. The device features a "data ready" interrupt line which
is pulled down once a new measurement is ready to be read.
Dumitru Ceclan [Mon, 12 Aug 2024 08:13:16 +0000 (11:13 +0300)]
iio: adc: ad7173: add support for ad4113
This commit adds support for the AD4113 ADC.
The AD4113 is a low power, low noise, 16-bit, Σ-Δ analog-to-digital
converter (ADC) that integrates an analog front end (AFE) for four
fully differential or eight single-ended inputs.
Dumitru Ceclan [Mon, 12 Aug 2024 08:13:14 +0000 (11:13 +0300)]
dt-bindings: adc: ad7173: add support for ad4113
This commit adds bindings support for AD4113.
The AD4113 is a low power, low noise, 16-bit, Σ-Δ analog-to-digital
converter (ADC) that integrates an analog front end (AFE) for four
fully differential or eight single-ended inputs.
Added ad4113 to the compatible list and the "avdd2-supply: false"
restriction.
'struct iio_map' are not modified in these drivers.
Constifying this structure moves some data to a read-only section, so
increase overall security.
In order to do it, the prototype of iio_map_array_register() and
devm_iio_map_array_register(), and a few structures that hold a
"struct iio_map *" need to be adjusted.
On a x86_64, with allmodconfig, as an example:
Before:
======
text data bss dec hex filename
21086 760 0 21846 5556 drivers/iio/adc/axp20x_adc.o
After:
=====
text data bss dec hex filename
21470 360 0 21830 5546 drivers/iio/adc/axp20x_adc.o
33842 1697 384 35923 8c53 drivers/iio/addac/ad74413r.o
Andy Shevchenko [Wed, 4 Sep 2024 18:45:43 +0000 (21:45 +0300)]
iio: imu: inv_mpu6050: Use upper_16_bits()/lower_16_bits() helpers
Use upper_16_bits()/lower_16_bits() helpers instead of open-coding them.
This is easier to scan quickly compared to bitwise manipulation, and
it is pleasingly symmetric.
When there is a change in the configuration of the BMP3xx device, several
steps take place. These steps include:
1) Update the OSR settings and check if there was an update
2) Update the ODR settings and check if there was an update
3) Update the IIR settings and check if there was an update
4) Check if there was an update with the following procedure:
a) Set sensor to SLEEP mode and after to NORMAL mode to trigger
a new measurement.
b) Wait the maximum amount possible depending on the OSR settings
c) Check the configuration error register if there was an error
during the configuration of the sensor.
This check is necessary, because there could be a case where the OSR is
too high for the requested ODR so either the ODR needs to be slower or the
OSR needs to be less. This is something that is checked internally by the
sensor when it runs in NORMAL mode.
In the BMP58x devices the previous steps are done internally by the sensor.
The IIR filter settings do not depend on the OSR or ODR settings, and there
is no need to run a check in case they change.
iio: pressure: bmp280: Add support for bmp280 soft reset
The BM(P/E)28x devices have an option for soft reset which is also
recommended by the Bosch Sensortech BME2 Sensor API to be used before the
initial configuration of the device.
'struct iio_chan_spec' are not modified in these drivers.
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
35749 5879 384 42012 a41c drivers/iio/addac/ad74115.o
32242 3297 384 35923 8c53 drivers/iio/addac/ad74413r.o
After:
=====
text data bss dec hex filename
39109 2519 384 42012 a41c drivers/iio/addac/ad74115.o
33842 1697 384 35923 8c53 drivers/iio/addac/ad74413r.o
leading to a build error when neither KVM_INTEL nor KVM_AMD support is
enabled:
arch/x86/kvm/x86.c: In function ‘kvm_arch_enable_virtualization’:
arch/x86/kvm/x86.c:12517:9: error: implicit declaration of function ‘cpu_emergency_register_virt_callback’ [-Wimplicit-function-declaration]
12517 | cpu_emergency_register_virt_callback(kvm_x86_ops.emergency_disable_virtualization_cpu);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/kvm/x86.c: In function ‘kvm_arch_disable_virtualization’:
arch/x86/kvm/x86.c:12522:9: error: implicit declaration of function ‘cpu_emergency_unregister_virt_callback’ [-Wimplicit-function-declaration]
12522 | cpu_emergency_unregister_virt_callback(kvm_x86_ops.emergency_disable_virtualization_cpu);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fix the build by defining empty helper functions the same way the old
cpu_emergency_disable_virtualization() function was dealt with for the
same situation.
Maybe we could instead have made the call sites conditional, since the
callers (kvm_arch_{en,dis}able_virtualization()) have an empty weak
fallback. I'll leave that to the kvm people to argue about, this at
least gets the build going for that particular config.
Fixes: 590b09b1d88e ("KVM: x86: Register "emergency disable" callbacks when virt is enabled") Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Kai Huang <kai.huang@intel.com> Cc: Chao Gao <chao.gao@intel.com> Cc: Farrah Chen <farrah.chen@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'mailbox-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox
Pull mailbox updates from Jassi Brar:
- fix kconfig dependencies (mhu-v3, omap2+)
- use devie name instead of genereic imx_mu_chan as interrupt name
(imx)
- enable sa8255p and qcs8300 ipc controllers (qcom)
- Fix timeout during suspend mode (bcm2835)
- convert to use use of_property_match_string (mailbox)
- enable mt8188 (mediatek)
- use devm_clk_get_enabled helpers (spreadtrum)
- fix device-id typo (rockchip)
* tag 'mailbox-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox:
mailbox, remoteproc: omap2+: fix compile testing
dt-bindings: mailbox: qcom-ipcc: Document QCS8300 IPCC
dt-bindings: mailbox: qcom-ipcc: document the support for SA8255p
dt-bindings: mailbox: mtk,adsp-mbox: Add compatible for MT8188
mailbox: Use of_property_match_string() instead of open-coding
mailbox: bcm2835: Fix timeout during suspend mode
mailbox: sprd: Use devm_clk_get_enabled() helpers
mailbox: rockchip: fix a typo in module autoloading
mailbox: imx: use device name in interrupt name
mailbox: ARM_MHU_V3 should depend on ARM64
Merge tag 'i2c-for-6.12-rc1-additional_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
- fix DesignWare driver ENABLE-ABORT sequence, ensuring ABORT can
always be sent when needed
- check for PCLK in the SynQuacer controller as an optional clock,
allowing ACPI to directly provide the clock rate
- KEBA driver Kconfig dependency fix
- fix XIIC driver power suspend sequence
* tag 'i2c-for-6.12-rc1-additional_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: xiic: Fix pm_runtime_set_suspended() with runtime pm enabled
i2c: keba: I2C_KEBA should depend on KEBA_CP500
i2c: synquacer: Deal with optional PCLK correctly
i2c: designware: fix controller is holding SCL low while ENABLE bit is disabled
projects / users / jedix / linux-maple.git / log