summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-02-17iio: health: afe4403: Use devm action helper for regulator disableAndrew Davis1-11/+16
Use a device lifecycle managed action for regulator disable function. This helps prevent mistakes like unregistering out of order in cleanup functions and forgetting to unregister on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123140918.215818-1-afd@ti.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17MAINTAINERS: add IIO GTS testsMatti Vaittinen1-0/+1
Add undersigned as a maintainer for IIO GTS helper's KUnit tests. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/52c66fe2798192529738ac2ab98a27230a6ad8cd.1705328293.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: test: test gain-time-scale helpersMatti Vaittinen3-0/+528
Some light sensors can adjust both the HW-gain and integration time. There are cases where adjusting the integration time has similar impact to the scale of the reported values as gain setting has. IIO users do typically expect to handle scale by a single writable 'scale' entry. Driver should then adjust the gain/time accordingly. It however is difficult for a driver to know whether it should change gain or integration time to meet the requested scale. Usually it is preferred to have longer integration time which usually improves accuracy, but there may be use-cases where long measurement times can be an issue. Thus it can be preferable to allow also changing the integration time - but mitigate the scale impact by also changing the gain underneath. Eg, if integration time change doubles the measured values, the driver can reduce the HW-gain to half. The theory of the computations of gain-time-scale is simple. However, some people (undersigned) got that implemented wrong for more than once. Hence some gain-time-scale helpers were introduced. Add some simple tests to verify the most hairy functions. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/0f7505b43f91394dc3bb636369489c897b7e01a7.1705328293.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: light: vcnl4000: Set ps high definition for 4040/4200Mårten Lindahl1-1/+35
The vcnl4040/vcnl4200 proximity sensor defaults to 12 bit data resolution, but the chip also supports 16 bit data resolution, which is called proximity high definition (PS_HD). Make the vcnl4040/vcnl4200 proximity sensor use the high definition for all data readings. Please note that in order to preserve the 12 bit integer part of the in_proximity_raw output, the format is changed from integer to fixed point. Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com> Link: https://lore.kernel.org/r/20231221-vcnl4000-ps-hd-v3-1-6dcc889372be@axis.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: adc: ad_sigma_delta: allow overwriting the IRQ flagsNuno Sa1-1/+6
Make sure we can specify the IRQ trigger type from firmware and drivers won't ignore it. In fact, this how it should be done but since someone might be already depending on the driver to hardcode the trigger type (and not specifying it in firmware), let's do it like this so there's no possible breakage. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240117-dev_sigma_delta_no_irq_flags-v1-2-db39261592cf@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: imu: adis16480: make use of irq_get_trigger_type()Nuno Sa1-8/+1
There's no need to call both irq_get_irq_data() and irqd_get_trigger_type() as we already have an helper for that. This allows for code simplification. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240117-adis-improv-v1-3-7f90e9fad200@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: imu: adis16475: make use of irq_get_trigger_type()Nuno Sa1-7/+1
There's no need to call both irq_get_irq_data() and irqd_get_trigger_type() as we already have an helper for that. This allows for code simplification. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240117-adis-improv-v1-2-7f90e9fad200@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: dummy_evgen: remove Excess kernel-doc commentsRandy Dunlap1-2/+0
Drop kernel-doc comments for struct fields that were removed to prevent kernel-doc warnings: iio_dummy_evgen.c:43: warning: Excess struct member 'irq_sim' description in 'iio_dummy_eventgen' iio_dummy_evgen.c:43: warning: Excess struct member 'base' description in 'iio_dummy_eventgen' Fixes: 337cbeb2c13e ("genirq/irq_sim: Simplify the API") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20240121055005.20042-1-rdunlap@infradead.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: adc: rtq6056: Add support for the whole RTQ6056 familyChiYuan Huang1-20/+255
RTQ6053 and RTQ6059 are the same series of RTQ6056. The respective differences with RTQ6056 are listed below RTQ6053 - chip package type RTQ6059 - Reduce the pinout for vbus sensing pin - Some internal ADC scaling change Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/3541207c4727e3a76b9a3caf88ef812a4d47b764.1704676198.git.cy_huang@richtek.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24dt-bindings: iio: adc: rtq6056: add support for the whole RTQ6056 familyChiYuan Huang1-1/+8
Add compatible support for RTQ6053 and RTQ6059. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/c1abb261bb00846f456eb8fe9b5919f59f287c24.1704676198.git.cy_huang@richtek.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: buffer-dmaengine: make use of the 'struct device *' argumentNuno Sa1-2/+1
Respect the @dev argument in devm_iio_dmaengine_buffer_setup() and bind the IIO DMA buffer lifetime to that device. For the only user of this function, the IIO parent device is the struct device being passed to the API so no real fix in here (just consistency with other IIO APIs). Signed-off-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20240109-dmaengine_use_device-v1-1-1cbdb7fe9f29@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: core: use INDIO_ALL_BUFFER_MODES in iio_buffer_enabled()David Lechner1-3/+1
This replaces use of individual buffer mode flags with INDIO_ALL_BUFFER_MODES in the iio_buffer_enabled() function. This simplifies the code and makes it robust in case of the addition of new buffer modes. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20240108200647.3916681-1-dlechner@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24MAINTAINERS: correct file entry for AD7091RAmit Dhingra1-1/+1
File entry has driver/iio/adc two times. Fix the file entry Found by ./scripts/get_maintainer.pl --self-test=patterns Signed-off-by: Amit Dhingra <mechanicalamit@gmail.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Link: https://lore.kernel.org/r/CAO=gReEUr4B+E2mQsSrncHf41f0A915SuoWgA522_2Ts-dZbSg@mail.gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24tools: iio: replace seekdir() in iio_generic_bufferPetre Rodan1-1/+1
Replace seekdir() with rewinddir() in order to fix a localized glibc bug. One of the glibc patches that stable Gentoo is using causes an improper directory stream positioning bug on 32bit arm. That in turn ends up as a floating point exception in iio_generic_buffer. The attached patch provides a fix by using an equivalent function which should not cause trouble for other distros and is easier to reason about in general as it obviously always goes back to to the start. https://sourceware.org/bugzilla/show_bug.cgi?id=31212 Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Link: https://lore.kernel.org/r/20240108103224.3986-1-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: invensense: remove redundant initialization of variable periodColin Ian King1-1/+1
The variable period is being initialized with a value that is never read, it is being re-assigned a new value later on before it is read. The initialization is redundant and can be removed. Cleans up clang scan build warning: Value stored to 'period' during its initialization is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20240106153202.54861-1-colin.i.king@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: accel: bmi088: add i2c support for bmi088 accel driverJun Yan3-2/+77
The BMI088, BMI085 and BMI090L accelerometer also support I2C protocol, so let's add the missing I2C support. The I2C interface of the {BMI085,BMI088,BMI090L} is compatible with the I2C Specification UM10204 Rev. 03 (19 June 2007), available at http://www.nxp.com. The {BMI085,BMI088,BMI090L} supports I2C standard mode and fast mode, only 7-bit address mode is supported. Datasheet: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmi085-ds001.pdf Datasheet: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmi088-ds001.pdf Datasheet: https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus/4807/BST-BMI090L-DS000-00.pdf Signed-off-by: Jun Yan <jerrysteve1101@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312191325.jfiyeL5F-lkp@intel.com/ Link: https://lore.kernel.org/r/20231219150440.264033-1-jerrysteve1101@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: adc: ti-adc109s102: drop ACPI_PTR() and CONFIG_ACPI guardsJonathan Cameron1-3/+1
The complexity of config guards needed for ACPI_PTR() is not worthwhile for the small amount of saved data. This example was doing it correctly but I am proposing dropping this so as to reduce chance of cut and paste where it is done wrong. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-25-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: light: max44000: drop ACPI_PTR() and CONFIG_ACPI guardsJonathan Cameron1-4/+2
The complexity of config guards needed for ACPI_PTR() is not worthwhile for the small amount of saved data. This example was doing it correctly but I am proposing dropping this so as to reduce chance of cut and paste where it is done wrong. Also drop now unneeded linux/acpi.h include and added linux/mod_devicetable.h for struct acpi_device_id definition. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-24-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: pressure: hp206c: drop ACPI_PTR() and CONFIG_ACPI guardsJonathan Cameron1-4/+2
The complexity of config guards needed for ACPI_PTR() is not worthwhile for the small amount of saved data. This example was doing it correctly but I am proposing dropping this so as to reduce chance of cut and paste where it is done wrong. Also drop now unneeded linux/acpi.h include and added linux/mod_devicetable.h for struct acpi_device_id definition. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-23-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: st_sensors: drop ACPI_PTR() and CONFIG_ACPI guardsJonathan Cameron2-8/+2
The complexity of config guards needed for ACPI_PTR() is not worthwhile for the small amount of saved data. This example was doing it correctly but I am proposing dropping this so as to reduce chance of cut and paste where it is done wrong. Also drop now unneeded linux/acpi.h include. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Denis CIOCCA <denis.ciocca@st.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-22-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: potentiometer: max5487: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Switch include from acpi.h to mod_devicetable.h which includes the definition of struct acpi_device_id. Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-21-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: magnetometer: mmc35240: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Switch include from acpi.h to mod_devicetable.h which includes the definition of struct acpi_device_id. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-20-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: magnetometer: bmc150: Drop ACPI_PTR() usageJonathan Cameron2-4/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Drop unused linux/acpi.h includes. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312040109.Csnmqnb2-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202311171116.47sUbZV5-lkp@intel.com/ Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-19-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: light: us5182d: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Switch include from acpi.h to mod_devicetable.h which includes the definition of struct acpi_device_id. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311190738.gldzuIXo-lkp@intel.com/ Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-18-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: light: stk3310: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Switch include from acpi.h to mod_devicetable.h which includes the definition of struct acpi_device_id. Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-17-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: light: rpr0521: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Switch include from acpi.h to mod_devicetable.h which includes the definition of struct acpi_device_id. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-16-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: light: ltr501: Drop ACPI_PTR() usageJonathan Cameron1-1/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Include linux/mod_devicetable.h which includes the definition of struct acpi_device_id (hence somewhat related to the main change) Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-15-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: light: jsa1212: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Switch include from acpi.h to mod_devicetable.h which includes the definition of struct acpi_device_id. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-14-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: imu: kmx61: Drop ACPI_PTR() usageJonathan Cameron1-1/+1
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-13-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: imu: fxos8700: Drop ACPI_PTR() usageJonathan Cameron2-4/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Drop unused acpi.h include. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311231427.vEQAuxvI-lkp@intel.com/ Cc: Carlos Song <carlos.song@nxp.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-12-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: humidity: hts221: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Switch include to mod_devicetable.h as that contains the only ACPI specific definitions needed in this driver. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-11-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: gyro: bmg160: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Switch include to mod_devicetable.h as that contains the only ACPI specific definitions needed in this driver. Cc: Mike Looijmans <mike.looijmans@topic.nl> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-10-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: accel: bmc150: Drop ACPI_PTR()Jonathan Cameron2-3/+2
In general the complexity of avoiding maybe unused variable warnings is not worth dealing with for the small amount of data saved. In thie case, the i2c driver does include some other code under a CONFIG_ACPI guard but remove the ACPI_PTR() usage anyway to bring keep it inline with the spi driver. Drop include of linux/acpi.h in the spi driver that doesn't need it as struct acpi_device_id is defined in mod_devicetable.h which is already included. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-9-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: accel: stk8ba50: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Switch include to mod_devicetable.h as that contains the only ACPI specific definitions needed in this driver. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-8-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: accel: mxc6255: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Switch include to mod_devicetable.h as that contains the only ACPI specific definitions needed in this driver. Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-7-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: accel: mxc4005: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Switch include to mod_devicetable.h as that contains the only ACPI specific definitions needed in this driver. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311181952.1usxCcup-lkp@intel.com/ Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-6-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: accel: mma9553: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Whilst here tidy up a trivial bit of unusual indentation. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-5-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: accel: mma9551: Drop ACPI_PTR() usageJonathan Cameron1-2/+2
Avoiding unused variable warnings when using this macro adds complexity that in simple cases like this one is not justified for the small saving in data. Whilst here tidy up a trivial bit of unusual indentation. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-4-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: accel: kxcjk-1013: Move acpi_device_id table under ifdef CONFIG_ACPIJonathan Cameron1-16/+17
This avoids a build warning due to the use of ACPI_PTR(). Given the driver already has APCI specific code under CONFIG_ACPI move the table rather than removing the ACPI_PTR() call as we already have the complexity of CONFIG_ACPI. Dropped a pointless comma after {} terminator whilst moving the code. Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-3-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: accel: da280: Stop using ACPI_PTR()Jonathan Cameron1-1/+1
In general using ACPI_PTR() leads to more fragile code for a very minor saving in storage in the case of !CONFIG_ACPI so in IIO we prefer not to use it if the only ACPI specific code is the acpi_device_id table. In this case will also suppress a unused variable warning. Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202302142222.vVU0E4eu-lkp@intel.com/ Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-2-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: pressure: mprls0025pa add SPI driverPetre Rodan3-1/+100
Add SPI component of the driver. Tested-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Link: https://lore.kernel.org/r/20231229092445.30180-11-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: pressure: mprls0025pa add triplet propertyPetre Rodan1-8/+97
Add honeywell,pressure-triplet property that automatically initializes pmin-pascal, pmax-pascal so that the user is not required to look-up the chip in the datasheet and convert various units to pascals himself. Co-developed-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Link: https://lore.kernel.org/r/20231229092445.30180-10-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: pressure: mprls0025pa refactor to split core and i2c parts.Petre Rodan6-133/+264
Refactor driver by splitting the code into core and i2c. Seemingly redundant read/write function parameters are required for compatibility with the SPI driver. Co-developed-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Link: https://lore.kernel.org/r/20231229092445.30180-9-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: pressure: mprls0025pa whitespace cleanupPetre Rodan1-18/+17
Fix indentation and whitespace in code that will not get refactored. Make URL inside comment copy-paste friendly. Co-developed-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Link: https://lore.kernel.org/r/20231229092445.30180-8-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: pressure: mprls0025pa remove defaultsPetre Rodan1-28/+20
This driver supports 32*3 combinations of fixed ranges and transfer functions, plus custom ranges. So statistically a user has more than 99% chance that the provided default configuration will generate invalid pressure readings if the bindings are not initialized and the driver is instantiated via sysfs. The current patch removes this loophole making sure the driver loads only if the firmware properties are present. Co-developed-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Link: https://lore.kernel.org/r/20231229092445.30180-7-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: pressure: mprls0025pa improve driver error resiliencePetre Rodan1-2/+4
Improve driver error resilience by ignoring the measurement if any of the 3 error flags gets set while interacting with the sensor. Based on the datasheet, in table 14 on page 14, the status byte contains: bit 5 busy flag - 1 if device is busy bit 2 memory integrity/error flag - 1 if integrity test failed bit 0 math saturation - 1 if internal math saturation has occurred Co-developed-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Link: https://lore.kernel.org/r/20231229092445.30180-6-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: pressure: mprls0025pa fix off-by-one enumPetre Rodan1-1/+3
Fix off-by-one error in transfer-function property. The honeywell,transfer-function property takes values between 1-3 so make sure the proper enum gets used. Fixes: 713337d9143ed ("iio: pressure: Honeywell mprls0025pa pressure sensor") Co-developed-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Link: https://lore.kernel.org/r/20231229092445.30180-5-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-22dt-bindings: iio: pressure: honeywell,mprls0025pa.yaml add spi busPetre Rodan1-2/+25
Add spi based example. Add spi-max-frequency property required by chip specifications. Add additional maintainer. Co-developed-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231229092445.30180-4-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-22dt-bindings: iio: pressure: honeywell,mprls0025pa.yaml add pressure-tripletPetre Rodan1-18/+46
Change order of properties in order for the end user to hopefully ignore pmin-pascal and pmax-pascal which are superseded by pressure-triplet. Add pressure-triplet property which automatically initializes pmin-pascal and pmax-pascal inside the driver. Rework honeywell,pmXX-pascal requirements based on feedback from Jonathan and Conor. Co-developed-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231229092445.30180-3-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-22dt-bindings: iio: pressure: honeywell,mprls0025pa.yaml improvementsPetre Rodan1-1/+6
Define enum inside the honeywell,transfer-function property block. Set the correct irq edge in the example block. Based on the datasheet, in table 13 on page 11: "End-of-conversion indicator: This pin is set high when a measurement and calculation have been completed and the data is ready to be clocked out" Add description on End-of-conversion interrupt. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Co-developed-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Link: https://lore.kernel.org/r/20231229092445.30180-2-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-30 14:07:19 +0300