iio: proximity: sx9360: Stop using iio_device_claim_direct_scoped()
This complex cleanup.h use case of conditional guards has proved
to be more trouble that it is worth in terms of false positive compiler
warnings and hard to read code.
Move directly to the new claim/release_direct() that allow sparse
to check for unbalanced context
iio: proximity: sx9324: Stop using iio_device_claim_direct_scoped()
This complex cleanup.h use case of conditional guards has proved
to be more trouble that it is worth in terms of false positive compiler
warnings and hard to read code.
Move directly to the new claim/release_direct() that allow sparse
to check for unbalanced context
iio: proximity: sx9310: Stop using iio_device_claim_direct_scoped()
This complex cleanup.h use case of conditional guards has proved
to be more trouble that it is worth in terms of false positive compiler
warnings and hard to read code.
Move directly to the new claim/release_direct() that allow sparse
to check for unbalanced context.
iio: temperature: tmp006: Stop using iio_device_claim_direct_scoped()
This complex cleanup.h use case of conditional guards has proved
to be more trouble that it is worth in terms of false positive compiler
warnings and hard to read code.
Move directly to the new claim/release_direct() that allow sparse
to check for unbalanced context.
iio: chemical: scd30: Use guard(mutex) to allow early returns
Auto cleanup based release of the lock allows for simpler code flow in a
few functions with large multiplexing style switch statements and no
common operations following the switch.
Suggested-by: David Lechner <dlechner@baylibre.com> Cc: Tomasz Duszynski <tomasz.duszynski@octakon.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250209180624.701140-3-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
However with that, sparse generates false positives. E.g.
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c:1811:17: warning: context imbalance in 'st_lsm6dsx_read_raw' - unexpected unlock
So instead, this patch rethinks the return type and makes it more
'conditional lock like' (which is part of what is going on under the hood
anyway) and return a boolean - true for successfully acquired, false for
did not acquire.
To allow a migration path given the rework is now non trivial, take a leaf
out of the naming of the conditional guard we currently have for IIO
device direct mode and drop the _mode postfix from the new functions giving
iio_device_claim_direct() and iio_device_release_direct()
Whilst the kernel supports __cond_acquires() upstream sparse does not
yet do so. Hence rely on sparse expanding a static inline wrapper
to explicitly see whether __acquire() is called.
Note that even with the solution here, sparse sometimes gives false
positives. However in the few cases seen they were complex code
structures that benefited from simplification anyway.
Bo Liu [Wed, 12 Feb 2025 07:52:23 +0000 (02:52 -0500)]
iio: accel: kx022a: convert to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Bo Liu [Wed, 12 Feb 2025 07:52:22 +0000 (02:52 -0500)]
iio: accel: bmi088: convert to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Bo Liu [Wed, 12 Feb 2025 07:52:21 +0000 (02:52 -0500)]
iio: accel: bma400: convert to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Bo Liu [Wed, 12 Feb 2025 07:52:20 +0000 (02:52 -0500)]
iio: accel: msa311: convert to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Tobias Sperling [Thu, 13 Feb 2025 15:58:58 +0000 (16:58 +0100)]
iio: adc: Add driver for ADS7128 / ADS7138
Add driver for ADS7128 and ADS7138 12-bit, 8-channel analog-to-digital
converters. These ADCs have a wide operating range and a wide feature
set. Communication is based on the I2C interface.
ADS7128 differs in the addition of further hardware features, like a
root-mean-square (RMS) and a zero-crossing-detect (ZCD) module.
Tobias Sperling [Thu, 13 Feb 2025 15:58:57 +0000 (16:58 +0100)]
dt-bindings: iio: adc: Introduce ADS7138
Add documentation for the driver of ADS7128 and ADS7138 12-bit, 8-channel
analog-to-digital converters. These ADCs have a wide operating range and
a wide feature set. Communication is based on the I2C interface.
ADS7128 differs in the addition of further hardware features, like a
root-mean-square (RMS) and a zero-crossing-detect (ZCD) module.
Esteban Blanc [Fri, 14 Feb 2025 12:22:35 +0000 (13:22 +0100)]
iio: adc: ad4030: add support for ad4632-16 and ad4632-24
AD4632-24 and AD4632-16 are 2 channels ADCs. Both channels are
interleaved bit per bit on SDO line.
Both of them do not have evaluation board. As such, the support added
here can't be tested. Support is provided as best effort until someone get
their hands on one.
Esteban Blanc [Fri, 14 Feb 2025 12:22:31 +0000 (13:22 +0100)]
dt-bindings: iio: adc: add ADI ad4030, ad4630 and ad4632
This adds a binding specification for the Analog Devices Inc. AD4030,
AD4630 and AD4632 families of ADCs.
- ad4030-24 is a 1 channel SAR ADC with 24 bits of precision and a
sampling rate of 2M samples per second
- ad4032-24 is a 1 channel SAR ADC with 24 bits of precision and a
sampling rate of 500K samples per second
- ad4630-16 is a 2 channels SAR ADC with 16 bits of precision and a
sampling rate of 2M samples per second
- ad4630-24 is a 2 channels SAR ADC with 24 bits of precision and a
sampling rate of 2M samples per second
- ad4632-16 is a 2 channels SAR ADC with 16 bits of precision and a
sampling rate of 500K samples per second
- ad4632-24 is a 2 channels SAR ADC with 24 bits of precision and a
sampling rate of 500K samples per second
Antoniu Miclaus [Fri, 14 Feb 2025 13:19:55 +0000 (15:19 +0200)]
iio: adc: ad4851: add ad485x driver
Add support for the AD485X a fully buffered, 8-channel simultaneous
sampling, 16/20-bit, 1 MSPS data acquisition system (DAS) with
differential, wide common-mode range inputs.
Guillaume Stols [Mon, 10 Feb 2025 16:10:59 +0000 (17:10 +0100)]
iio: adc: ad7606: add support for writing registers when using backend
Add the logic for effectively enabling the software mode for the
iio-backend, i.e. enabling the software mode channel configuration and
implementing the register writing functions.
Add the possibility to pass the *_available parameters to the main
macro.
This is a preparation to add the new channels for software mode and
hardware mode in iio backend mode more easily.
Guillaume Stols [Mon, 10 Feb 2025 16:10:56 +0000 (17:10 +0100)]
iio: adc: adi-axi-adc: add support for AD7606 register writing
Since we must access the bus parallel bus using a custom procedure,
let's add a specialized compatible, and define specialized callbacks for
writing the registers using the parallel interface.
iio: adc: adi-axi-adc: add platform children support
This is a preparation for the next commit adding support for register
read and write functions on AD7606.
Since sometimes a bus will be used, it has been agreed during ad3552's
driver implementation that the device's driver bus is the backend, whose
device node will be a child node.
To provide the special callbacks for setting the register, axi-adc needs
to pass them to the child device's driver through platform data.
Guillaume Stols [Mon, 10 Feb 2025 16:10:53 +0000 (17:10 +0100)]
iio: adc: ad7606: move software functions into common file
Since the register are always the same, whatever bus is used, moving the
software functions into the main file avoids the code to be duplicated
in both SPI and parallel version of the driver.
Guillaume Stols [Mon, 10 Feb 2025 16:10:52 +0000 (17:10 +0100)]
iio: adc: ad7606: move the software mode configuration
This is a preparation for the intoduction of the sofware functions in
the iio backend version of the driver.
The software mode configuration must be executed once the channels are
configured, and the number of channels is known. This is not the case
before iio-backend's configuration is called, and iio backend version of
the driver does not have a timestamp channel.
Also the sw_mode_config callback is configured during the iio-backend
configuration.
For clarity purpose, I moved the entire block instead of just the
concerned function calls.
A new compatible is added to reflect the specialized version of the HDL.
We use the parallel interface to write the ADC's registers, and
accessing this interface requires to use ADI_AXI_REG_CONFIG_RD,
ADI_AXI_REG_CONFIG_WR and ADI_AXI_REG_CONFIG_CTRL in a custom fashion.
Trevor Gamblin [Thu, 9 Jan 2025 18:47:24 +0000 (13:47 -0500)]
doc: iio: ad4695: describe oversampling support
Add a section to the ad4695 documentation describing how to use the
oversampling feature. Also add some clarification on how the
oversampling ratio influences effective sample rate in the offload
section.
Trevor Gamblin [Thu, 9 Jan 2025 18:47:23 +0000 (13:47 -0500)]
iio: adc: ad4695: add offload-based oversampling support
Add support for the ad4695's oversampling feature when SPI offload is
available. This allows the ad4695 to set oversampling ratios on a
per-channel basis, raising the effective-number-of-bits from 16
(OSR == 1) to 17 (4), 18 (16), or 19 (64) for a given sample (i.e. one
full cycle through the auto-sequencer). The logic for reading and
writing sampling frequency for a given channel is also adjusted based on
the current oversampling ratio.
The non-offload case isn't supported as there isn't a good way to
trigger the CNV pin in this mode. Support could be added in the future
if a use-case arises.
Add a pwms property to the adi,ad4695 binding to specify an optional PWM
output connected to the CNV pin on the ADC.
Also add #trigger-source-cells property to allow the BUSY output to be
used as a SPI offload trigger source to indicate when a sample is ready
to be read.
Macros are added to adi,ad4695.h for the cell values to help with
readability since they are arbitrary values.
David Lechner [Fri, 7 Feb 2025 20:09:07 +0000 (14:09 -0600)]
iio: adc: ad7944: don't use storagebits for sizing
Replace use of storagebits with realbits for determining the number of
bytes needed for SPI transfers.
When adding SPI offload support, storagebits will always be 32 rather
than 16 for 16-bit 16-bit chips so we can no longer rely on storagebits
being the correct size expected by the SPI framework (it always uses
4 bytes for > 16-bit xfers and 2 bytes for > 8-bit xfers). Instead,
derive the correct size from realbits since it will always be correct
even when SPI offloading is used.
Add a new devm_iio_dmaengine_buffer_setup_with_handle() function to
handle cases where the DMA channel is managed by the caller rather than
being requested and released by the iio_dmaengine module.
David Lechner [Fri, 7 Feb 2025 20:09:05 +0000 (14:09 -0600)]
iio: buffer-dmaengine: split requesting DMA channel from allocating buffer
Refactor the IIO dmaengine buffer code to split requesting the DMA
channel from allocating the buffer. We want to be able to add a new
function where the IIO device driver manages the DMA channel, so these
two actions need to be separate.
To do this, calling dma_request_chan() is moved from
iio_dmaengine_buffer_alloc() to iio_dmaengine_buffer_setup_ext(). A new
__iio_dmaengine_buffer_setup_ext() helper function is added to simplify
error unwinding and will also be used by a new function in a later
patch.
iio_dmaengine_buffer_free() now only frees the buffer and does not
release the DMA channel. A new iio_dmaengine_buffer_teardown() function
is added to unwind everything done in iio_dmaengine_buffer_setup_ext().
This keeps things more symmetrical with obvious pairs alloc/free and
setup/teardown.
Calling dma_get_slave_caps() in iio_dmaengine_buffer_alloc() is moved so
that we can avoid any gotos for error unwinding.
The ad4130 driver exports in_voltageY-voltageZ_filter_mode and
in_voltage-voltage_filter_mode_available attributes to user space. A
previous patch merged the documentation for those attributes with the
documentation for filter_type/filter_type_available into sysfs-bus-iio.
Filter mode and filter type refer to the same feature which is the digital
filter applied over ADC samples. However, since datasheets use the term
`filter type` and ad4130 driver is the only one using filter_mode,
deprecate the filter_mode ABI in favor of filter_type and keep the docs
separate to avoid confusion and intricate attribute descriptions.
A previous patch added documentation for filter_type_available attributes.
However, the description for the value attribute (filter_type) was missing.
Add documentation for filter_type sysfs ABI.
iio: adc: ad7124: Really disable all channels at probe time
If one or more of the 16 channels are enabled and the driver is not
aware of that, unexpected things happen because different channels are
used than intended. To prevent that, all channels should be disabled at
probe time. In Commit 4be339af334c ("iio: adc: ad7124: Disable all
channels at probe time") I intended do that, however only the channels
that are potentially used by the driver and not all channels are
disabled since then. So disable all 16 channels and not only the used
ones.
Also fix the same issue in the .disable_all() callback.
Javier Carrasco [Mon, 27 Jan 2025 19:30:23 +0000 (20:30 +0100)]
iio: light: veml6030: fix scale to conform to ABI
The current scale is not ABI-compliant as it is just the sensor gain
instead of the value that acts as a multiplier to be applied to the raw
value (there is no offset).
Use the iio-gts helpers to obtain the proper scale values according to
the gain and integration time to match the resolution tables from the
datasheet and drop dedicated variables to store the current values of
the integration time, gain and resolution. When at it, use 'scale'
instead of 'gain' consistently for the get/set functions to avoid
misunderstandings.
Fixes: 7b779f573c48 ("iio: light: add driver for veml6030 ambient light sensor") Acked-by: Matti Vaittinen <mazziesaccount@gmail.com> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://patch.msgid.link/20250127-veml6030-scale-v3-2-4f32ba03df94@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Javier Carrasco [Mon, 27 Jan 2025 19:30:22 +0000 (20:30 +0100)]
iio: gts-helper: export iio_gts_get_total_gain()
Export this function in preparation for the fix in veml6030.c, where the
total gain can be used to ease the calculation of the processed value of
the IIO_LIGHT channel compared to acquiring the scale in NANO.
Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://patch.msgid.link/20250127-veml6030-scale-v3-1-4f32ba03df94@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Silicon Labs Si7210 is an I2C Hall effect magnetic position and
temperature sensor. The driver supports the following functionalities:
* reading the temperature measurements
* reading the magnetic field measurements in a single-shot mode
* choosing the magnetic field measurement scale (20 or 200 mT)
Javier Carrasco [Sun, 19 Jan 2025 17:31:59 +0000 (18:31 +0100)]
iio: light: veml6030: extend regmap to support caching
The configuration registers are not volatile and are not affected
by read operations (i.e. not precious), making them suitable to be
cached in order to reduce the number of accesses to the device.
The key objective in ad7124_disable_one() is clearing the
AD7124_CHANNEL_EN_MSK bit in the channel register. However there is no
advantage to keep the other bits in that register because when the
channel is used next time, all fields are rewritten anyhow. So instead
of using ad7124_spi_write_mask() (which is a register read plus a
register write) use a simple register write clearing the complete
register.
Also do the same in the .disable_all() callback by using the
.disable_one() callback there.
David Lechner [Wed, 22 Jan 2025 23:16:59 +0000 (17:16 -0600)]
iio: dac: ad5791: fix storage
IIO uses "natural" alignment so storagebits should always be a power of
2. Change storagebits to 32 since that is the natural size to store 24
bits of data.
The ad5791 driver currently doesn't use this field anywhere and doesn't
support buffered writes, so this does not change anything. We just don't
want anyone to think that it is OK to have storagebits = 24 in other
drivers.
Gwendal Grignou [Tue, 21 Jan 2025 23:20:07 +0000 (15:20 -0800)]
iio: cros_ec: Trace EC sensors command
For debugging, add tracing for EC_CMD_MOTION_SENSE_CMD command:
- decode the name of the subcommand
- provide internal information for the most common sub-commands:
setting range, frequency, EC probing frequency, ...
- display return status.
When enabled, the tracing output is similar to:
/sys/kernel/debug/tracing # echo 1 > events/cros_ec/enable ; echo 1 > tracing_on ; cat trace_pipe | grep MOTIONSENSE_CMD_SENSOR_ODR
SensorDeviceImp-814 [003] ..... 686.176782: cros_ec_motion_host_cmd: MOTIONSENSE_CMD_SENSOR_ODR, id: 1, data: 200000, result: 4, return: 12500
A new FPGA HDL has been developed from ADI to support ad354xr
devices.
Add support for ad3541r and ad3542r with following additions:
- use common device_info structures for hs and non hs drivers,
- DMA buffering, use DSPI mode for ad354xr and QSPI for ad355xr,
- change sample rate to respect number of lanes.
Preparing for new parts to be added also in the hs driver,
set model data structures in ad3552r-common.c, to be accessible
from both -hs and non hs driver.
iio: dac: ad3552r-hs: use instruction mode for configuration
Use "instruction" mode over initial configuration and all other
non-streaming operations.
DAC boots in streaming mode as default, and the driver is not
changing this mode.
Instruction r/w is still working because instruction is processed
from the DAC after chip select is deasserted, this works until
loop mode is 0 or greater than the instruction size.
All initial operations should be more safely done in instruction
mode, a mode provided for this.
The ad354xr requires DSPI mode (2 data lanes) to work in buffering
mode, so, depending on the DAC type, target TRANSFER_REGISTER
"MULTI_IO_MODE" bitfield can be set between:
SPI (configuration, entire ad35xxr family),
DSPI (ad354xr),
QSPI (ad355xr).
Also bus IO_MODE must be set accordingly.
About removal of AXI_DAC_CUSTOM_CTRL_SYNCED_TRANSFER, according to
the HDL history the flag has never been used. So looks like the driver
was including it by mistake or in anticipation for something that was
never implemented on HDL side.
Current HDL updated documentation confirm it is actually not in use
anymore and replaced by the IO_MODE bits.
David Lechner [Fri, 7 Feb 2025 20:09:02 +0000 (14:09 -0600)]
spi: add offload TX/RX streaming APIs
Most configuration of SPI offloads is handled opaquely using the offload
pointer that is passed to the various offload functions. However, there
are some offload features that need to be controlled on a per transfer
basis.
This patch adds a flag field to struct spi_transfer to allow specifying
such features. The first feature to be added is the ability to stream
data to/from a hardware sink/source rather than using a tx or rx buffer.
Additional flags can be added in the future as needed.
A flags field is also added to the offload struct for providers to
indicate which flags are supported. This allows for generic checking of
offload capabilities during __spi_validate() so that each offload
provider doesn't have to implement their own validation.
As a first users of this streaming capability, getter functions are
added to get a DMA channel that is directly connected to the offload.
Peripheral drivers will use this to get a DMA channel and configure it
to suit their needs.
David Lechner [Fri, 7 Feb 2025 20:08:59 +0000 (14:08 -0600)]
spi: offload: add support for hardware triggers
Extend SPI offloading to support hardware triggers.
This allows an arbitrary hardware trigger to be used to start a SPI
transfer that was previously set up with spi_optimize_message().
A new struct spi_offload_trigger is introduced that can be used to
configure any type of trigger. It has a type discriminator and a union
to allow it to be extended in the future. Two trigger types are defined
to start with. One is a trigger that indicates that the SPI peripheral
is ready to read or write data. The other is a periodic trigger to
repeat a SPI message at a fixed rate.
There is also a spi_offload_hw_trigger_validate() function that works
similar to clk_round_rate(). It basically asks the question of if we
enabled the hardware trigger what would the actual parameters be. This
can be used to test if the requested trigger type is actually supported
by the hardware and for periodic triggers, it can be used to find the
actual rate that the hardware is capable of.
David Lechner [Fri, 7 Feb 2025 20:08:58 +0000 (14:08 -0600)]
spi: add basic support for SPI offloading
Add the basic infrastructure to support SPI offload providers and
consumers.
SPI offloading is a feature that allows the SPI controller to perform
transfers without any CPU intervention. This is useful, e.g. for
high-speed data acquisition.
SPI controllers with offload support need to implement the get_offload
and put_offload callbacks and can use the devm_spi_offload_alloc() to
allocate offload instances.
SPI peripheral drivers will call devm_spi_offload_get() to get a
reference to the matching offload instance. This offload instance can
then be attached to a SPI message to request offloading that message.
It is expected that SPI controllers with offload support will check for
the offload instance in the SPI message in the ctlr->optimize_message()
callback and handle it accordingly.
CONFIG_SPI_OFFLOAD is intended to be a select-only option. Both
consumer and provider drivers should `select SPI_OFFLOAD` in their
Kconfig to ensure that the SPI core is built with offload support.
Change suggested from the AXI HDL team, modify the function
axi_dac_data_stream_enable() to check for interface busy, to avoid
possible issues when starting the stream.
Matti Vaittinen [Mon, 16 Dec 2024 08:56:37 +0000 (10:56 +0200)]
iio: gts: Simplify available scale table build
Make available scale building more clear. This hurts the performance
quite a bit by looping throgh the scales many times instead of doing
everything in one loop. It however simplifies logic by:
- decoupling the gain and scale allocations & computations
- keeping the temporary 'per_time_gains' table inside the
per_time_scales computation function.
- separating building the 'all scales' table in own function and doing
it based on the already computed per-time scales.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Tested-by: subhajit.ghosh@tweaklogic.com Link: https://patch.msgid.link/Z1_rRXqdhxhL6wBw@mva-rohm Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fabio Estevam [Mon, 9 Dec 2024 18:16:24 +0000 (15:16 -0300)]
iio: adc: ti-ads124s08: Switch to fsleep()
According to Documentation/timers/delay_sleep_functions.rst,
fsleep() is the preferred delay function to be used in non-atomic
context, so switch to it accordingly.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Fabio Estevam <festevam@denx.de> Link: https://patch.msgid.link/20241209181624.1260868-1-festevam@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Trevor Gamblin [Wed, 13 Nov 2024 20:53:00 +0000 (15:53 -0500)]
iio: adc: ad4695: add custom regmap bus callbacks
Add a custom implementation of regmap read/write callbacks using the SPI
bus. This allows them to be performed at a lower SCLK rate than data
reads. Previously, all SPI transfers were being performed at a lower
speed, but with this change sample data is read at the max bus speed
while the register reads/writes remain at the lower rate.
Also remove .can_multi_write from the AD4695 driver's regmap_configs, as
this isn't implemented or needed.
Trevor Gamblin [Wed, 13 Nov 2024 20:52:59 +0000 (15:52 -0500)]
iio: adc: ad4695: make ad4695_exit_conversion_mode() more robust
Ensure that conversion mode is successfully exited when the command is
issued by adding an extra transfer beforehand, matching the minimum CNV
high and low times from the AD4695 datasheet. The AD4695 has a quirk
where the exit command only works during a conversion, so guarantee this
happens by triggering a conversion in ad4695_exit_conversion_mode().
Then make this even more robust by ensuring that the exit command is run
at AD4695_REG_ACCESS_SCLK_HZ rather than the bus maximum.
Replace ternary (condition ? "enable" : "disable") syntax with helpers
from string_choices.h because:
1. Simple function call with one argument is easier to read. Ternary
operator has three arguments and with wrapping might lead to quite
long code.
2. Is slightly shorter thus also easier to read.
3. It brings uniformity in the text - same string.
4. Allows deduping by the linker, which results in a smaller binary
file.
Trevor Gamblin [Tue, 14 Jan 2025 17:31:55 +0000 (12:31 -0500)]
iio: adc: ad7625: drop BSD license tag
The ad7625 driver was submitted under a dual BSD/GPL license, but this
isn't a requirement for the code, and adds extra complexity. To make it
consistent with similar drivers, drop the BSD tag and leave it as
GPL-2.0-only.
David Lechner [Mon, 13 Jan 2025 21:43:19 +0000 (15:43 -0600)]
iio: adc: ad7173: don't make copy of ad_sigma_delta_info struct
Use two separate static const struct ad_sigma_delta_info instances
instead of making a copy for each driver instance.
Typically in the IIO subsystem, we use multiple static const instances
of the same struct when there are different variants of the same family
of devices as opposed to making a copy for each driver instance and
modifying it.
David Lechner [Mon, 13 Jan 2025 21:43:18 +0000 (15:43 -0600)]
iio: adc: ad7173: move fwnode_irq_get_byname() call site
Move the call to fwnode_irq_get_byname() from the driver-specific
ad7173_fw_parse_device_config() to the shared ad_sd_init() function.
The main reason for this is that we want struct ad_sigma_delta_info to
be static const data that describes the actual ADC chip, not the
application-specific configuration or any runtime state.
Previously, this struct was being used to pass the IRQ number to the
shared ad_sd_init() function. Now, this is replaced by a boolean flag
that is set at compile time and the ad_sd_init() function handles
looking up the IRQ number instead. This also has the added benefit that
if any other drivers need to make use of this in the future, they just
have to set the flag and the shared code will take care of the rest
rather than duplicating the code in each driver.
iio: adc: stm32: Drop unnecessary DT property presence check
There's no reason to check for regulator supply property presence before
calling devm_regulator_get_optional() as that will return -ENODEV if
the supply is not present.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Tested-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://patch.msgid.link/20250109182325.3973684-2-robh@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
projects / thirdparty / kernel / linux.git / log
