summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)Author
2019-11-27Merge tag 'char-misc-5.5-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver updates from Greg KH: "Here is the big set of char/misc and other driver patches for 5.5-rc1 Loads of different things in here, this feels like the catch-all of driver subsystems these days. Full details are in the shortlog, but nothing major overall, just lots of driver updates and additions. All of these have been in linux-next for a while with no reported issues" * tag 'char-misc-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (198 commits) char: Fix Kconfig indentation, continued habanalabs: add more protection of device during reset habanalabs: flush EQ workers in hard reset habanalabs: make the reset code more consistent habanalabs: expose reset counters via existing INFO IOCTL habanalabs: make code more concise habanalabs: use defines for F/W files habanalabs: remove prints on successful device initialization habanalabs: remove unnecessary checks habanalabs: invalidate MMU cache only once habanalabs: skip VA block list update in reset flow habanalabs: optimize MMU unmap habanalabs: prevent read/write from/to the device during hard reset habanalabs: split MMU properties to PCI/DRAM habanalabs: re-factor MMU masks and documentation habanalabs: type specific MMU cache invalidation habanalabs: re-factor memory module code habanalabs: export uapi defines to user-space habanalabs: don't print error when queues are full habanalabs: increase max jobs number to 512 ...
2019-11-27Merge tag 'for-v5.5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply and reset updates from Sebastian Reichel: - test_power: add support for current and charge_counter - cpcap-charger: improve charge calculation and limit default charge voltage - ab8500: convert to IIO - misc small fixes all over drivers * tag 'for-v5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (29 commits) power: supply: bd70528: Add MODULE_ALIAS to allow module auto loading power: supply: ab8500_charger: Fix inconsistent IS_ERR and PTR_ERR power: supply: cpcap-charger: cpcap_charger_voltage_to_regval() can be static power: supply: cpcap-battery: Add basic coulomb counter calibrate support power: supply: cpcap-battery: Read and save integrator register CCI power: supply: cpcap-battery: Simplify short term power average calculation power: supply: cpcap-battery: Simplify coulomb counter calculation with div_s64 power: supply: cpcap-battery: Move coulomb counter units per lsb to ddata power: supply: cpcap-charger: Allow changing constant charge voltage power: supply: cpcap-battery: Fix handling of lowered charger voltage power: supply: cpcap-charger: Improve battery detection power: supply: cpcap-battery: Check voltage before orderly_poweroff power: supply: cpcap-charger: Limit voltage to 4.2V for battery power: supply: ab8500: Handle invalid IRQ from platform_get_irq_byname() power: supply: ab8500_fg: Do not free non-requested IRQs in probe's error path power: supply: ab8500: Cleanup probe in reverse order power: reset: at91: fix __le32 cast in reset code power: supply: abx500_chargalg: Fix code indentation mfd: Switch the AB8500 GPADC to IIO iio: adc: New driver for the AB8500 GPADC ...
2019-11-23iio: dac: ad7303: use regulator get optional to check for ext supplyAlexandru Tachici
Previously, the code was using the of_read_property_bool() to check if an external regulator was provided. However, this is redundant, as it's more simple/direct to just ask the regulator is provided, via a `devm_regulator_get_optional()` call. Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: maxim_thermocouple: add thermocouple_type sysfs attributeAndrea Merello
We added a sysfs ABI for getting/setting the type of a thermocouple. This driver supports chips that support specific fixed thermocouple types; we cannot set it, but still we can add this sysfs attribute in RO mode to read-back the thermocouple type. This driver supports actually several chips: - max6675 - max31855[k/j/n/s/t/e/r]asa family Max6675 supports only K-type thermocouples, so we can just report that. Each chip in max31855 family supports just one specific thermocouple type (in the obvious way: i.e. max31855jasa supports J-type). This driver did accept a generic SPI ID and OF compatible "max31855" which does not give any clue about which chip is really involved (and unfortunately it seems we have no way to detect it). This patch introduces a new set of, more specific, SPI IDs and OF compatible strings to better match the chip type. The old, generic, "max31855" binding is kept for compatibility reasons, but this patch aims to deprecate it, so, should we hit it, a warning is spit. In such case the reported thermocouple type in sysfs is '?', because we have no way to know. Regarding the implementation: the thermocouple type information is stored in the driver private data and I've kept only two maxim_thermocouple_chip types in order to avoid a lot of duplications (seven chip types with just a different thermocouple type). RFT because I have no real HW to test this. Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: devicetree@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: max31856: add support for runtime-configuring the thermocouple typeAndrea Merello
The sensor support various thermocouple types (e.g. J, K, N, ...). The driver allows to configure this parameter using a DT property. This is useful when i.e. the thermocouple is physically tied to the sensor and it is usually not removed, or when it is at least known in advance which sensor will be connected to the circuit. However, if the user can randomly connect any kind of thermocouples (i.e. the device exposes a connector, and the user is free to connect its own sensors), it would be more appropriate to provide a mechanism to dynamically switch from one thermocouple type to another. This can be i.e. handled in userspace by a GUI, a configuration file or a program that detects the thermocouple type by reading a GPIO, or a eeprom on the probe, or whatever. This patch adds a IIO attribute that can be used to override, at run-time, the DT-provided setting (which serves as default). Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: core: add thermocouple_type standard attributeAndrea Merello
We have a couple of thermocouple IIO drivers, supporting several chips. Some of them support only one specific thermocouple type (e.g. "K", "J"), one of them can be configured to work with several different thermocouple types. In certain applications thermocouples could be externally connected to the chip by the user. This patch introduces a new IIO standard attribute to report the supported thermocouple type and, where applicable, to allow it to be dynamically set using sysfs. Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: core: add char type for sysfs attributesAndrea Merello
This patch introduces IIO_VAL_CHAR type for standard IIO attributes to allow for attributes that needs to be represented by character rather than a number. This is preparatory for introducing a new attribute whose purpose is to describe thermocouple type, that can be i.e. "J", "K", etc.. The char-type value is stored in the first "value" integer that is passed to the .[read/write]_raw() callbacks. Note that in order to make it possible for the IIO core to correctly parse this type (actually, to avoid integer parsing), it became mandatory for any driver that wish to use IIO_VAL_CHAR on a writable attribute to implement .write_raw_get_fmt(). Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: max31856: add support for configuring the HW averagingAndrea Merello
This sensor can perform samples averaging in hardware, but currently the driver leaves this setting alone (default is no averaging). This patch binds this HW setting to the "oversampling_ratio" IIO attribute and allows the user to set the averaging as desired (the HW supports averaging of 2, 5, 8 or 16 samples; in-between values are rounded up). Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: max31856: add option for setting mains filter rejection frequencyAndrea Merello
This sensor has an embedded notch filter for reducing interferences caused by the power mains. This filter can be tuned to reject either 50Hz or 60Hz (and harmonics). Currently the said setting is left alone (the sensor defaults to 60Hz). This patch introduces a IIO attribute that allows the user to set the said filter to the desired frequency. NOTE: this has been intentionally not tied to any DT property to allow the configuration of this setting from userspace, e.g. with a GUI or by reading a configuration file, or maybe reading a GPIO tied to a physical switch or accessing some device that can autodetect the line frequency. Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: gyro: adis16260: replace mlock with ADIS lib's state_lockAlexandru Ardelean
This change uses the ADIS library's state_lock to protect the state of the `max_speed_hz` change that is done during the set of the sampling frequency. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: imu: adis16480: use state lock for filter freq setAlexandru Ardelean
It's the only operation that does 2 operations (a read & a write), so the unlocked functions can be used under a single state lock. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: gyro: adis16136: rework locks using ADIS library's state lockAlexandru Ardelean
This replaces indio_dev's mlock with the state lock/mutex from the ADIS library. The __adis16136_get_freq() function has been prefixed to mark it as unlocked. The adis16136_{set,get}_filter() functions now hold the state lock for all the ops that they do. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: imu: adis16400: rework locks using ADIS library's state lockAlexandru Ardelean
This change removes the use of indio_dev's mlock in favor using the state lock from the ADIS library. The set_freq() & get_freq() hooks are unlocked, so they require specific locking. That is because in some cases the get_freq() hook is used in combination with adis16400_set_filter(). In cases where only one read/write is done, the functions that hold the state lock are used. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: imu: adis: group single conversion under a single state lockAlexandru Ardelean
The single conversion function does a series of reads + writes. This change extends the use of the state_lock for the entire set of operations. Previously, indio_dev's mlock was used. This change also removes the use of this lock. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: imu: adis: protect initial startup routine with state lockAlexandru Ardelean
The initial startup routine is called by some ADIS drivers during probe, and before registering with IIO. Normally, userspace should not be able to do any access to the device (as there shouldn't be any available). This change extends the state lock to the entire initial-startup routine. Behaviourally nothing should change, but this should make the library function a bit more robust. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: imu: adis: create an unlocked version of adis_reset()Alexandru Ardelean
The reset routine may also be important to be protected by the state-lock and grouped with other operations, so create an unlocked version, so that this can be done. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: imu: adis: create an unlocked version of adis_check_status()Alexandru Ardelean
This one also gets re-used in certain operations, so it makes sense to have an unlocked version of this to group it with other reads/writes/operations to have a single lock for the whole state change. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: imu: adis[16480]: group RW into a single lock in adis_enable_irq()Alexandru Ardelean
The adis_enable_irq() does a read & a write. This change keeps a lock for the duration of both operations vs for each op. The change is also needed in adis16480, since that has it's own implementation for adis_enable_irq(). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: imu: adis: add unlocked read/write function versionsAlexandru Ardelean
This will allow more flexible control to group reads & writes into a single lock (particularly the state_lock). The end-goal is to remove the indio_dev->mlock usage, and the simplest fix would have been to just add another lock, which would not be a good idea on the long-run. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-23iio: imu: adis: rename txrx_lock -> state_lockAlexandru Ardelean
The lock can be extended a bit to protect other elements that are not particular to just TX/RX. Another idea would have been to just add a new `state_lock`, but that would mean 2 locks which would be redundant, and probably cause more potential for dead-locks. What will be done in the next patches, will be to add some unlocked versions for read/write_reg functions. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-22Merge branch 'spi-5.5' into spi-nextMark Brown
2019-11-21mfd / platform / iio: cros_ec: Register sensor through sensorhubGwendal Grignou
Remove the duplicated code in MFD, since MFD just registers cros-ec-sensorhub if at least one sensor is present. Change IIO cros-ec driver to get the pointer to the cros-ec-dev through cros-ec-sensorhub. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21iio / platform: cros_ec: Add cros-ec-sensorhub driverGwendal Grignou
Similar to HID sensor stack, the new driver sits between cros-ec-dev and the IIO device drivers: The EC based IIO device topology would be: iio:device1 -> ...0/0000:00:1f.0/PNP0C09:00/GOOG0004:00/cros-ec-dev.6.auto/ cros-ec-sensorhub.7.auto/ cros-ec-accel.15.auto/ iio:device1 It will be expanded to control EC sensor FIFO. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> [Fix "unknown type name 'uint32_t'" type errors] Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-16iio: adc: max9611: Make enum relations more future proofGeert Uytterhoeven
The relations between enum values and array indices values are currently not enforced by the code, which makes them fragile w.r.t. future changes. Fix this by: 1. Using designated array initializers, to make sure array indices and enums values match, 2. Linking max9611_csa_gain enum values to the corresponding max9611_conf_ids enum values, as the latter is cast to the former in max9611_read_csa_voltage(). No change in generated code. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-16iio: imu: inv_mpu6050: add support of MPU9150 magnetometerJean-Baptiste Maneyrol
Add support for driving MPU9150 magnetometer (AK8975) from mpu. Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-16iio: imu: inv_mpu6050: delete not existing MPU9150 spi supportJean-Baptiste Maneyrol
MPU9150 is i2c only. Update Kconfig to delete in description chips that are i2c or spi only. Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-16iio: adc: ad7091r5: Add scale and external VREF supportPaul Cercueil
The scale can now be obtained with the "in_voltage_scale" file. By default, the scale returned corresponds to the internal VREF of 2.5V. It is possible to use an external VREF (through the REFIN/REFOUT pin of the chip), by passing a regulator to the driver. The scale will then be calculated according to the voltage reported by the regulator. Signed-off-by: Paul Cercueil <paul.cercueil@analog.com> Co-developed-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-16iio: adc: Add support for AD7091R5 ADCPaul Cercueil
AD7091R5 is 4-Channel, I2C, Ultra Low Power,12-Bit ADC. This driver will also support AD7091R2/4/8 in the future. Datasheet: Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf Signed-off-by: Paul Cercueil <paul.cercueil@analog.com> Co-developed-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-16iio: buffer-dmaengine: Use dma_request_chan() directly for channel requestPeter Ujfalusi
dma_request_slave_channel_reason() is: dma_request_chan(dev, name) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-13Merge tag 'iio-for-5.5c' of ↵Greg Kroah-Hartman
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: Third set of IIO new device support cleanups and fixes for the 5.5 cycle. New device support * ad5446 - Support the ad5600 DAC (id only needed). * ad7292 ADC DAC etc - New driver plus dt-bindings. * veml6030 ambient light sensor - New driver plus dt-bindings and sysfs docs. Features * mpu6050 - Explicit VDD control. * stm32-adc - Allow limiting of max clock frequency from devicetree to ensure it's suitable for external circuitry. yaml binding conversions * ltc1660 * mcp3911 Fixes * adis16480 - Fix wrong scale factors. - Fix debugfs reg access by providing the callback. * cros_ec_baro - Fixing missing mask entry to make available sample frequencies visible in sysfs. * st_lsm6dsx - Explicitly handle different ODR table sizes. - Handle restrictions between slave ODR and accel ODR when both are enabled. - Allow ODR to be expressed more accurately by using miliHz. * tools - Fix an issue with parallel builds. Cleanups and warning fixes * adis16136, adis16400, adis16460, adis-lib - Change some checks on return values to be for 0 rather than strictly negative. Avoids some fiddly issues with the compiler concluding some variables are initialized due to a mixture of error checks. - Assign values only on success of 'read' operations - avoiding any chance the compiler will falsly suggest they might be used uninitialized. - Whitespace and simlar cleanups. * aspeed adc - devm_platfom_ioremap_resource to reduce boilerplate. * bcm-iproc-adc - Stray semicolon removal. * cc10001 - devm_platfom_ioremap_resource to reduce boilerplate. * dln2-adc - Reorganise the buffered mode setup and tear down. Part of moving towards being able to refactor this area of the IIO core. * hdc100x - Reorganise the buffered mode setup and tear down. * ingenic-adc - devm_platfom_ioremap_resource to reduce boilerplate. * lpc18xx-adc - devm_platfom_ioremap_resource to reduce boilerplate. * lpc18xx-dac - devm_platfom_ioremap_resource to reduce boilerplate. * mt6577 - devm_platfom_ioremap_resource to reduce boilerplate. * npcm - devm_platfom_ioremap_resource to reduce boilerplate. * rcar-gyroadc - devm_platfom_ioremap_resource to reduce boilerplate. * spear-adc - devm_platfom_ioremap_resource to reduce boilerplate. * vf610-adc - devm_platfom_ioremap_resource to reduce boilerplate. * vf610-dac - devm_platfom_ioremap_resource to reduce boilerplate. * tag 'iio-for-5.5c' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (43 commits) iio: adis16480: Add debugfs_reg_access entry iio: adis16480: Fix scales factors tools: iio: Correctly add make dependency for iio_utils iio: adc: Add driver support for AD7292 dt-bindings: iio: adc: Add dt-schema for AD7292 dt-bindings: iio: adc: Migrate MCP3911 documentation to yaml iio: imu: mpu6050: Add support for vdd-supply regulator dt-bindings: iio: imu: mpu6050: add vdd-supply iio: cros_ec_baro: set info_mask_shared_by_all_available field iio: dac: ad5446: Add support for new AD5600 DAC dt-bindings: iio: dac: Migrate LTC1660 documentation to yaml iio: documentation: light: Add veml6030 sysfs documentation dt-bindings: iio: light: add veml6030 ALS bindings iio: light: add driver for veml6030 ambient light sensor iio: imu: st_lsm6dsx: express odr in mHZ iio: imu: st_lsm6dsx: fix ODR check in st_lsm6dsx_write_raw iio: imu: st_lsm6dsx: explicitly define odr table size iio: adc: stm32: allow to tune analog clock dt-bindings: iio: stm32-adc: add max clock rate property iio: dac: vf610: Use devm_platform_ioremap_resource ...
2019-11-11iio: adis16480: Add debugfs_reg_access entryNuno Sá
The driver is defining debugfs entries by calling `adis16480_debugfs_init()`. However, those entries are attached to the iio_dev debugfs entry which won't exist if no debugfs_reg_access callback is provided. Fixes: 2f3abe6cbb6c ("iio:imu: Add support for the ADIS16480 and similar IMUs") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-11iio: adis16480: Fix scales factorsNuno Sá
This patch fixes the scales for the gyroscope, accelerometer and barometer. The pressure scale was just wrong. For the others, the scale factors were not taking into account that a 32bit word is being read from the device. Fixes: 7abad1063deb ("iio: adis16480: Fix scale factors") Fixes: 82e7a1b25017 ("iio: imu: adis16480: Add support for ADIS1649x family of devices") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-11Merge 5.4-rc7 into char-misc-nextGreg Kroah-Hartman
We need the char/misc driver fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-11Merge 5.4-rc7 into staging-nextGreg Kroah-Hartman
We want the staging fixes in here, and it resolves some merge issues. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-10iio: adc: Add driver support for AD7292Marcelo Schmitt
The AD7292 is a 10-bit monitor and control system with ADC, DACs, temperature sensor, and GPIOs. Configure AD7292 devices in direct access mode, enabling single-ended ADC readings. Datasheet: Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ad7292.pdf Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-10iio: imu: mpu6050: Add support for vdd-supply regulatorStephan Gerhold
MPU6050 has two power supply pins: VDD and VLOGIC, but the mpu6050 driver only supports enabling one of them at the moment. In some cases, they may need to be enabled separately. Add an additional "vdd-supply" that stays enabled for as long as the driver is loaded. We cannot turn off the VDD regulator during suspend as this would cause register settings (FSR, sampling rate, ...) to be lost. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-10iio: cros_ec_baro: set info_mask_shared_by_all_available fieldGwendal Grignou
Field was already set for light/proximity and accelerometer/gyroscope/magnetometer sensors. Fixes: ae7b02ad2f32 ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs") Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-10iio: dac: ad5446: Add support for new AD5600 DACStefan Popa
The AD5600 is a single channel, 16-bit resolution, voltage output digital to analog converter (DAC). The AD5600 uses a 3-wire SPI interface. It is part of the AD5541 family of DACs. The ad5446 IIO driver implements support for some of these DACs (in the AD5441 family), so the change is a simple entry in this driver. Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD5600.pdf Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-10iio: light: add driver for veml6030 ambient light sensorRishi Gupta
veml6030 is an ambient light sensor from Vishay semiconductors. It has 16-bit resolution, supports both ambient light measurement and white channel which is more responsive to wider wavelength spectrum. It has flexible power saving, integration time and gain options. Communication with host is over I2C. Signed-off-by: Rishi Gupta <gupt21@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-09iio: imu: st_lsm6dsx: express odr in mHZLorenzo Bianconi
Express available frequencies in mHZ in order to support even rational ODRs. This patch is need to fix an Android CTS failure Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-09iio: imu: st_lsm6dsx: fix ODR check in st_lsm6dsx_write_rawLorenzo Bianconi
Since st_lsm6dsx i2c master controller relies on accel device as trigger and slave devices can run at different ODRs we must select an accel_odr >= slave_odr. Report real accel ODR in st_lsm6dsx_check_odr() in order to properly set sensor frequency in st_lsm6dsx_write_raw and avoid to report unsupported frequency Fixes: 6ffb55e5009ff ("iio: imu: st_lsm6dsx: introduce ST_LSM6DSX_ID_EXT sensor ids") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-09iio: imu: st_lsm6dsx: explicitly define odr table sizeLorenzo Bianconi
Introduce odr_len in st_lsm6dsx_odr_table_entry data structure in order to explicitly define odr table size and support devices with different odr table map Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-09iio: adc: stm32: allow to tune analog clockFabrice Gasnier
Add new optional dt property to tune analog clock prescaler. Driver looks for optional "st,max-clk-rate-hz", then computes best approximation below that rate, using ADC internal prescaler. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-09iio: dac: vf610: Use devm_platform_ioremap_resourceJonathan Cameron
Reduce local boilerplate. Suggested by coccinelle CHECK drivers/iio/dac/vf610_dac.c drivers/iio/dac/vf610_dac.c:189:1-11: WARNING: Use devm_platform_ioremap_resource for info -> regs Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Sanchayan Maity <maitysanchayan@gmail.com>
2019-11-09iio: dac: lpc18xx: Use devm_platform_ioremap_resourceJonathan Cameron
Reduce boilerplate. Suggested by coccinelle CHECK drivers/iio/dac/lpc18xx_dac.c drivers/iio/dac/lpc18xx_dac.c:121:1-10: WARNING: Use devm_platform_ioremap_resource for dac -> base Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> CC: Joachim Eastwood <manabian@gmail.com>
2019-11-09iio: adc: vf610: use devm_platform_ioremap_resourceJonathan Cameron
Reduces boilerplate. Suggested by coccinelle CHECK drivers/iio/adc/vf610_adc.c drivers/iio/adc/vf610_adc.c:819:1-11: WARNING: Use devm_platform_ioremap_resource for info -> regs Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Fugang Duan <b38611@freescale.com>
2019-11-09iio: adc: spear_adc: Use devm_platform_ioremap_resourceJonathan Cameron
Avoids local boilerplate doing the same thing. Suggested by coccinelle CHECK drivers/iio/adc/spear_adc.c drivers/iio/adc/spear_adc.c:283:1-22: WARNING: Use devm_platform_ioremap_resource for st -> adc_base_spear6xx Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
2019-11-09iio: adc: rcar-gyroadc: use devm_platform_ioremap_resourceJonathan Cameron
Avoids some local boilerplate. Suggested by coccinelle. CHECK drivers/iio/adc/rcar-gyroadc.c drivers/iio/adc/rcar-gyroadc.c:495:1-11: WARNING: Use devm_platform_ioremap_resource for priv -> regs Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>
2019-11-09iio: adc: npcm: use devm_platform_ioremap_resourceJonathan Cameron
Reduces local boilerplate code. Suggested by coccinelle via coccicheck. CHECK drivers/iio/adc/npcm_adc.c drivers/iio/adc/npcm_adc.c:200:1-11: WARNING: Use devm_platform_ioremap_resource for info -> regs Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Tomer Maimon <tmaimon77@gmail.com>
2019-11-09iio: adc: lpc18xx: use devm_platform_ioremap_resourceJonathan Cameron
Avoid local boilerplate. Identified by coccinelle CHECK drivers/iio/adc/lpc18xx_adc.c drivers/iio/adc/lpc18xx_adc.c:137:1-10: WARNING: Use devm_platform_ioremap_resource for adc -> base Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Joachim Eastwood <manabian@gmail.com>
generated by cgit (git 2.34.1) at 2025-09-20 13:21:42 +0000