summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)AuthorFilesLines
2020-12-15Merge tag 'staging-5.11-rc1' of ↵Linus Torvalds75-906/+2020
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging / IIO driver updates from Greg KH: "Here is the big staging and IIO driver pull request for 5.11-rc1 Lots of different things in here: - loads of driver updates - so many coding style cleanups - new IIO drivers - Android ION code is finally removed from the tree - wimax drivers are moved to staging on their way out of the kernel Nothing really exciting, just the constant grind of kernel development :) All have been in linux-next for a while with no reported issues" * tag 'staging-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (341 commits) staging: olpc_dcon: Do not call platform_device_unregister() in dcon_probe() staging: most: Fix spelling mistake "tranceiver" -> "transceiver" staging: qlge: remove duplicate word in comment staging: comedi: mf6x4: Fix AI end-of-conversion detection staging: greybus: Add TODO item about modernizing the pwm code pinctrl: ralink: add a pinctrl driver for the rt2880 family dt-bindings: pinctrl: rt2880: add binding document staging: rtl8723bs: remove ELEMENT_ID enum staging: rtl8723bs: remove unused macros staging: rtl8723bs: replace EID_EXTCapability staging: rtl8723bs: replace EID_BSSIntolerantChlReport staging: rtl8723bs: replace EID_BSSCoexistence staging: rtl8723bs: replace _MME_IE_ staging: rtl8723bs: replace _WAPI_IE_ staging: rtl8723bs: replace _EXT_SUPPORTEDRATES_IE_ staging: rtl8723bs: replace _ERPINFO_IE_ staging: rtl8723bs: replace _CHLGETXT_IE_ staging: rtl8723bs: replace _COUNTRY_IE_ staging: rtl8723bs: replace _IBSS_PARA_IE_ staging: rtl8723bs: replace _TIM_IE_ ...
2020-12-03iio: adc: rockchip_saradc: fix missing clk_disable_unprepare() on error in ↵Qinglang Miao1-1/+1
rockchip_saradc_resume Fix the missing clk_disable_unprepare() of info->pclk before return from rockchip_saradc_resume in the error handling case when fails to prepare and enable info->clk. Suggested-by: Robin Murphy <robin.murphy@arm.com> Fixes: 44d6f2ef94f9 ("iio: adc: add driver for Rockchip saradc") Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201103120743.110662-1-miaoqinglang@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: imu: st_lsm6dsx: fix edge-trigger interruptsLorenzo Bianconi1-5/+21
If we are using edge IRQs, new samples can arrive while processing current interrupt since there are no hw guarantees the irq line stays "low" long enough to properly detect the new interrupt. In this case the new sample will be missed. Polling FIFO status register in st_lsm6dsx_handler_thread routine allow us to read new samples even if the interrupt arrives while processing previous data and the timeslot where the line is "low" is too short to be properly detected. Fixes: 89ca88a7cdf2 ("iio: imu: st_lsm6dsx: support active-low interrupts") Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/5e93cda7dc1e665f5685c53ad8e9ea71dbae782d.1605378871.git.lorenzo@kernel.org Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: sysfs-trigger: Mark irq_work to expire in hardirq contextLars-Peter Clausen1-0/+1
Mark the IIO sysfs-trigger irq_work with IRQ_WORK_HARD_IRQ to ensure that it is always executed in hard interrupt context, even with PREEMPT_RT=y. The IIO sysfs-trigger irq_work needs to run in hard interrupt context since it will end up calling generic_handle_irq() which has the requirement to run in hard interrupt context. Note that the IRQ_WORK_HARD_IRQ flag, while it exists, does not seem to do anything in the mainline kernel yet. It does have an effect in the RT patchset though and presumably this is sooner or later going to be added to mainline as well. Reported-by: Christian Eggers <ceggers@arri.de> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20201117103751.16131-2-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: hrtimer-trigger: Mark hrtimer to expire in hard interrupt contextLars-Peter Clausen1-2/+2
On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. The IIO hrtimer-trigger needs to run in hard interrupt context since it will end up calling generic_handle_irq() which has the requirement to run in hard interrupt context. Explicitly specify that the timer needs to run in hard interrupt context by using the HRTIMER_MODE_REL_HARD flag. Fixes: f5c2f0215e36 ("hrtimer: Move unmarked hrtimers to soft interrupt expiry on RT") Reported-by: Christian Eggers <ceggers@arri.de> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20201117103751.16131-1-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: accel: bmc150: Get mount-matrix from ACPIHans de Goede1-4/+104
bmc150 accelerometers with an ACPI hardware-id of BOSC0200 have an ACPI method providing their mount-matrix, add support for retrieving this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201130141954.339805-3-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: accel: bmc150: Check for a second ACPI device for BOSC0200Jeremy Cline3-2/+62
Some BOSC0200 acpi_device-s describe two accelerometers in a single ACPI device. Normally we would handle this by letting the special drivers/platform/x86/i2c-multi-instantiate.c driver handle the BOSC0200 ACPI id and let it instantiate 2 bmc150_accel type i2c_client-s for us. But doing so changes the modalias for the first accelerometer (which is already supported and used on many devices) from acpi:BOSC0200 to i2c:bmc150_accel. The modalias is not only used to load the driver, but is also used by hwdb matches in /lib/udev/hwdb.d/60-sensor.hwdb which provide a mountmatrix to userspace by setting the ACCEL_MOUNT_MATRIX udev property. Switching the handling of the BOSC0200 over to i2c-multi-instantiate.c will break the hwdb matches causing the ACCEL_MOUNT_MATRIX udev prop to no longer be set. So switching over to i2c-multi-instantiate.c is not an option. Changes by Hans de Goede: -Add explanation to the commit message why i2c-multi-instantiate.c cannot be used -Also set the dev_name, fwnode and irq i2c_board_info struct members for the 2nd client Signed-off-by: Jeremy Cline <jeremy@jcline.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201130141954.339805-2-hdegoede@redhat.com BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198671 Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: accel: bmc150: Removed unused bmc150_accel_dat irq memberHans de Goede1-5/+2
The bmc150_accel_dat struct irq member is only ever used inside bmc150_accel_core_probe, drop it and just use the function argument directly. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201130141954.339805-1-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio:gyro:mpu3050 Treat otp value as a __le64 and use FIELD_GET() to break upJonathan Cameron1-12/+16
Inspired by Andy Shevchenko's proposal to use get_unaligned_leXX(). The whole one time programable memory is treated as a single 64bit little endian value. Thus we can avoid a lot of messy handling of fields overlapping byte boundaries by just loading and manipulating it as an __le64 converted to a u64. That lets us just use FIELD_GET() and GENMASK() to extract the values desired. Note only build tested. We need to use GENMASK_ULL and %llX formatters to account for the larger types used in computing the various fields. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201128185156.428327-1-jic23@kernel.org Link: https://lore.kernel.org/r/20201129184459.647538-1-jic23@kernel.org
2020-12-03iio:adc:ti-ads124s08: Fix alignment and data leak issues.Jonathan Cameron1-3/+10
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc() so no data can leak apart from previous readings. In this driver the timestamp can end up in various different locations depending on what other channels are enabled. As a result, we don't use a structure to specify it's position as that would be misleading. Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Dan Murphy <dmurphy@ti.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-9-jic23@kernel.org
2020-12-03iio:adc:ti-ads124s08: Fix buffer being too long.Jonathan Cameron1-1/+1
The buffer is expressed as a u32 array, yet the extra space for the s64 timestamp was expressed as sizeof(s64)/sizeof(u16). This will result in 2 extra u32 elements. Fix by dividing by sizeof(u32). Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code") Signed-off-by: Jonathan Cameron<Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Dan Murphy <dmurphy@ti.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-8-jic23@kernel.org
2020-12-03iio:pressure:mpl3115: Force alignment of bufferJonathan Cameron1-1/+8
Whilst this is another case of the issue Lars reported with an array of elements of smaller than 8 bytes being passed to iio_push_to_buffers_with_timestamp(), the solution here is a bit different from the other cases and relies on __aligned working on the stack (true since 4.6?) This one is unusual. We have to do an explicit memset() each time as we are reading 3 bytes into a potential 4 byte channel which may sometimes be a 2 byte channel depending on what is enabled. As such, moving the buffer to the heap in the iio_priv structure doesn't save us much. We can't use a nice explicit structure on the stack either as the data channels have different storage sizes and are all separately controlled. Fixes: cc26ad455f57 ("iio: Add Freescale MPL3115A2 pressure / temperature sensor driver") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Peter Meerwald <pmeerw@pmeerw.net> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-7-jic23@kernel.org
2020-12-03iio:imu:bmi160: Fix alignment and data leak issuesJonathan Cameron2-4/+9
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable array in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc() so no data can leak apart from previous readings. In this driver, depending on which channels are enabled, the timestamp can be in a number of locations. Hence we cannot use a structure to specify the data layout without it being misleading. Fixes: 77c4ad2d6a9b ("iio: imu: Add initial support for Bosch BMI160") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Daniel Baluta <daniel.baluta@gmail.com> Cc: Daniel Baluta <daniel.baluta@oss.nxp.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org
2020-12-03iio:imu:bmi160: Fix too large a buffer.Jonathan Cameron1-2/+2
The comment implies this device has 3 sensor types, but it only has an accelerometer and a gyroscope (both 3D). As such the buffer does not need to be as long as stated. Note I've separated this from the following patch which fixes the alignment for passing to iio_push_to_buffers_with_timestamp() as they are different issues even if they affect the same line of code. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Daniel Baluta <daniel.baluta@oss.nxp.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-5-jic23@kernel.org
2020-12-03iio:magnetometer:mag3110: Fix alignment and data leak issues.Jonathan Cameron1-4/+9
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data. This data is allocated with kzalloc() so no data can leak apart from previous readings. The explicit alignment of ts is not necessary in this case but does make the code slightly less fragile so I have included it. Fixes: 39631b5f9584 ("iio: Add Freescale mag3110 magnetometer driver") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org
2020-12-03iio:light:st_uvis25: Fix timestamp alignment and prevent data leak.Jonathan Cameron2-3/+10
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() This data is allocated with kzalloc() so no data can leak apart from previous readings. A local unsigned int variable is used for the regmap call so it is clear there is no potential issue with writing into the padding of the structure. Fixes: 3025c8688c1e ("iio: light: add support for UVIS25 sensor") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-3-jic23@kernel.org
2020-12-03iio:light:rpr0521: Fix timestamp alignment and prevent data leak.Jonathan Cameron1-4/+13
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv(). This data is allocated with kzalloc() so no data can leak apart from previous readings and in this case the status byte from the device. The forced alignment of ts is not necessary in this case but it potentially makes the code less fragile. >From personal communications with Mikko: We could probably split the reading of the int register, but it would mean a significant performance cost of 20 i2c clock cycles. Fixes: e12ffd241c00 ("iio: light: rpr0521 triggered buffer") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Mikko Koivunen <mikko.koivunen@fi.rohmeurope.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-2-jic23@kernel.org
2020-12-03iio:adc:ti-adc084s021 Tidy up endian typesJonathan Cameron1-5/+5
By adding a few local variables and avoiding a void * for a parameter we can easily make all the endian types explicit and get rid of the warnings from sparse: CHECK drivers/iio/adc/ti-adc084s021.c drivers/iio/adc/ti-adc084s021.c:84:26: warning: incorrect type in assignment (different base types) drivers/iio/adc/ti-adc084s021.c:84:26: expected unsigned short [usertype] drivers/iio/adc/ti-adc084s021.c:84:26: got restricted __be16 drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16 drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16 drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16 drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16 Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200722155103.979802-23-jic23@kernel.org
2020-12-03iio:trigger: rename try_reenable() to reenable() plus return voidJonathan Cameron10-59/+38
As we no longer support a try again if we cannot reenable the trigger rename the function to reflect this. Also we don't do anything with the value returned so stop it returning anything. For the few drivers that didn't already print an error message in this patch, add such a print. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Christian Oder <me@myself5.de> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Nishant Malpani <nish.malpani25@gmail.com> Cc: Daniel Baluta <daniel.baluta@oss.nxp.com> Link: https://lore.kernel.org/r/20200920132548.196452-3-jic23@kernel.org
2020-12-03iio: Fix: Do not poll the driver again if try_reenable() callback returns non 0.Jonathan Cameron1-3/+1
The original reason for this behaviour is long gone and no current drivers are making use of this function correctly. Note however, that you would be very unlucky to actually hit the problem as it would require a bus comms failure in the callback. This dates back a long way. The original board on which I did a lot of early IIO development only supported edge interrupts, but some of the sensors were level interrupt based. As such, the lis3l02dq driver did a dance with checking a GPIO to identify if it should retrigger. That was an unsustainable hack so we later just stopped supporting interrupts for that particular combination. There are a number of drivers where a fault on a bus read in the try_reenable() callback will result in them returning non 0 and incorrectly then causing iio_trigger_poll() to be called. Anyhow, this handling is unused and causing issues so let us rip it out. Link: https://lore.kernel.org/linux-iio/20200813075358.13310-1-lars@metafoo.de/ After this the try_reenable() naming makes no sense, so as a follow up patch I'll rename it to simply reenable(). I haven't done that here as it will add noise to the fix for backporting. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Christian Eggers <ceggers@arri.de> Link: https://lore.kernel.org/r/20200920132548.196452-2-jic23@kernel.org
2020-12-03io:core: In iio_map_array_register() cleanup in case of errorLino Sanfilippo1-0/+2
In function iio_map_array_register() properly rewind in case of error. Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1606571059-13974-2-git-send-email-LinoSanfilippo@gmx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio:core: Introduce unlocked version of iio_map_array_unregister()Lino Sanfilippo1-9/+18
Introduce an unlocked version of iio_map_array_unregister(). This function can help to unwind in case of error while the iio_map_list_lock mutex is held. Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1606571059-13974-1-git-send-email-LinoSanfilippo@gmx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: imu: st_lsm6dsx: add support to LSM6DSOPLorenzo Bianconi6-3/+19
Add support to STM LSM6DSOP (acc + gyro) Mems sensor https://www.st.com/resource/en/datasheet/lsm6dsop.pdf Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/d3c459ad945ccd1a256f4a217128be214b0c024e.1606642528.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: imu: st_lsmdsx: compact st_lsm6dsx_sensor_settings tableLorenzo Bianconi2-425/+29
Shrink st_lsm6dsx_sensor_settings table size moving wai address info in id array and remove duplicated code Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/c43286938b2fe03ab3abdb5fc095ea6b950abcb1.1606557946.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: adc: at91_adc: merge at91_adc_probe_dt back in at91_adc_probeAlexandre Belloni1-67/+48
at91_adc_probe_dt is now small enough to be merged back in at91_adc_probe. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20201128222818.1910764-8-alexandre.belloni@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: adc: at91_adc: rework trigger definitionAlexandre Belloni1-44/+36
Move the available trigger definition back in the driver to stop cluttering the device tree. There is no functional change except that it actually fixes the available triggers for at91sam9rl as it inherited the list from at91sam9260 but actually has the triggers from at91sam9x5. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20201128222818.1910764-6-alexandre.belloni@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: adc: at91_adc: rework resolution selectionAlexandre Belloni1-57/+40
Move the possible resolution values back to the driver. This removes the atmel,adc-res and atmel,adc-res-names properties, leaving only atmel,adc-use-res. As atmel,adc-res-names had to contain "lowres" and "highres", those where already the only allowed values for atmel,adc-use-res. Also introduce a new compatible string for the sama5d3 as this is the only one with a different resolution. Also it doesn't even have the LOWRES bit. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20201128222818.1910764-3-alexandre.belloni@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: adc: at91_adc: remove at91_adc_idsAlexandre Belloni1-20/+0
The driver is DT only since commit ead1c9f376db ("iio: adc: at91_adc: remove platform data and move defs in driver file"). Remove the leftover platform_device_id array. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201128222818.1910764-2-alexandre.belloni@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: buffer: Fix demux updateNuno Sá1-3/+3
When updating the buffer demux, we will skip a scan element from the device in the case `in_ind != out_ind` and we enter the while loop. in_ind should only be refreshed with `find_next_bit()` in the end of the loop. Note, to cause problems we need a situation where we are skippig over an element (channel not enabled) that happens to not have the same size as the next element. Whilst this is a possible situation we haven't actually identified any cases in mainline where it happens as most drivers have consistent channel storage sizes with the exception of the timestamp which is the last element and hence never skipped over. Fixes: 5ada4ea9be16 ("staging:iio: add demux optionally to path from device to buffer") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20201112144323.28887-1-nuno.sa@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: core: Simplify iio_format_list()Lars-Peter Clausen1-27/+18
iio_format_list() has two branches in a switch statement that are almost identical. They only differ in the stride that is used to iterate through the item list. Consolidate this into a common code path to simplify the code. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20201114120000.6533-2-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: core: Consolidate iio_format_avail_{list,range}()Lars-Peter Clausen1-43/+14
The iio_format_avail_list() and iio_format_avail_range() functions are almost identical. The only differences are that iio_format_avail_range() expects a fixed amount of items and adds brackets "[ ]" around the output. Refactor them into a common helper function. This improves the maintainability of the code as it makes it easier to modify the implementation of these functions. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20201114120000.6533-1-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: potentiometer: ad5272: Correct polarity of resetPhil Reid1-2/+2
The driver should assert reset by setting the gpio high, and then release it by setting it the gpio low. This allows the device tree (or other hardware definition) to specify how the gpio is configured. For example as open drain or push-pull depending on the connected hardware. Signed-off-by: Phil Reid <preid@electromag.com.au> Link: https://lore.kernel.org/r/20201124050014.4453-1-preid@electromag.com.au Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: accel: bmc150-accel: Add rudimentary regulator supportLinus Walleij1-2/+33
These Bosch accelerometers have two supplies, VDD and VDDIO. Add some rudimentary support to obtain and enable these regulators during probe() and disable them during remove() or on the errorpath. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201115205745.618455-3-linus.walleij@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: accel: bmc150-accel: Add support for BMA222Linus Walleij4-0/+22
This adds support for the BMA222 version of this sensor, found in for example the Samsung GT-I9070 mobile phone. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201115205745.618455-2-linus.walleij@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: ad_sigma_delta: Don't put SPI transfer buffer on the stackLars-Peter Clausen1-10/+8
Use a heap allocated memory for the SPI transfer buffer. Using stack memory can corrupt stack memory when using DMA on some systems. This change moves the buffer from the stack of the trigger handler call to the heap of the buffer of the state struct. The size increases takes into account the alignment for the timestamp, which is 8 bytes. The 'data' buffer is split into 'tx_buf' and 'rx_buf', to make a clearer separation of which part of the buffer should be used for TX & RX. Fixes: af3008485ea03 ("iio:adc: Add common code for ADI Sigma Delta devices") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201124123807.19717-1-alexandru.ardelean@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: buffer: Return error if no callback is givenNuno Sá1-0/+5
Return error in case no callback is provided to `iio_channel_get_all_cb()`. There's no point in setting up a buffer-cb if no callback is provided. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20201121161457.957-3-nuno.sa@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: humidity: hts221: add vdd voltage regulatorLorenzo Bianconi2-0/+39
Like all other ST sensors, hts221 devices have VDD power line. Introduce VDD voltage regulator to control it. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/6b3347e78f4f920c48eb6a66936d3b69cb9ff53a.1606045688.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: adc: ad7298: check regulator for null in ad7298_get_ref_voltage()Alexandru Ardelean1-1/+1
'st->ext_ref' & 'st->reg' are both non-zero/non-null at the same time, so logically the code isn't broken. But it is more correct to check that 'st->reg' is non-null, since we make sure that the regulator is NULL (in probe) in case one isn't defined. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201127094038.91714-2-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-28iio: adc: ad7298: convert probe to device-managed functionsAlexandru Ardelean1-31/+15
This change converts the probe of this driver to use device-managed register functions, and a devm_add_action_or_reset() for the regulator disable. With this, the exit & error paths can be removed. Another side-effect is that this should avoid some static-analyzer's check with respect to a potential null dereference of the regulator. The null dereference isn't likely to happen (under normal operation), so there isn't a requirement to have this fixed/backported in other releases. As a note: this is removing spi_set_drvdata() since there is no other spi_get_drvdata() (or dev_get_drvdata()) call that need it. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201127094038.91714-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-25iio: imu: st_lsm6dsx: add vdd-vddio voltage regulatorLorenzo Bianconi2-0/+43
Like all other ST sensors, st_lsm6dsx devices have VDD and VDDIO power lines. Introduce voltage regulators to control them. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/a0427a66360bdec73c3b1fb536a46240f96b2ae7.1605631305.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-24Merge tag 'iio-for-5.11a' of ↵Greg Kroah-Hartman47-275/+1544
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: First set of new device support, features and cleanups for IIO in the 5.11 cycle Usual mixed bag of new drivers / device support + cleanups etc with the addition of a fairly big set of yaml conversions. Txt to yaml format conversions. In some cases dropped separate binding and moved to trivial devices (drop). Listed by manufacturer - dht11 temperature(drop) - adi,ad2s90 adi,ad5272 adi,ad5592r adi,ad5758 adi,ad5933 adi,ad7303 adi,adis16480 adi,adf4350 - ams,as3935 - asahi-kasei,ak8974 - atmel,sama5d2-adc - avago,apds9300 avago,apds9960 - bosch,bma180 bosch,bmc150_magn bosch,bme680 bosch,bmg180 - brcm,iproc-static-adc - capella,cm36651 - domintech,dmard06(drop) - fsl,mag3110 fsl,mma8452 fsl,vf610-dac - hoperf,hp03 - honeywell,hmc5843 - kionix,kxcjk1013 - maxim,ds1803(drop) maxim,ds4424 maxim,max30100 maxim,max30102 maxim,max31856 maxim,max31855k maxim,max44009 maxim,max5481 maxim,max5821 - meas,htu21(drop) meas,ms5367(drop) meas,ms5611 meas,tsys01(drop) - mediatek,mt2701-auxadc - melexis,mlx90614 melexis,mlx90632 - memsic,mmc35240(drop) - microchip,mcp41010 microchip,mcp4131 microchip,mcp4725 - murata,zap2326 - nxp,fxas21002c nxp,lpc1850-dac - pni,rm3100 - qcom,pm8018-adc qcom,spmi-iadc - renesas,isl29501 renesas,rcar-gyroadc - samsung,sensorhub-rinato - sensiron,sgp30 - sentech,sx9500 - sharp,gp2ap020a00f - st,hts221 st,lsm6dsx st,st-sensors(many!) st,uvis25 st,vcl53l0x st,vl6180 - ti,adc084s021 ti,ads124s08 ti,dac5571 ti,dac7311 ti,dac7512 ti,dac7612 ti,hdc1000(drop) ti,palmas-gpadc ti,opt3001 ti,tmp07 - upisemi,us51882 - vishay,vcnl4035 - x-powers,axp209 New device support * adi,ad5685 - Add support for AD5338R dual output 10-bit DAC - Add DT-binding doc. * mediatek,mt6360 - New driver for this SoC ADC with bindings and using new channel label support in the IIO core. * st,lsm6dsx - Add support for LSM6DST Core: * Add "label" to device channels, provided via a new core callback. Including DT docs for when that is the source, and ABI docs. * Add devm_iio_triggered_buffer_setup_ext to take extra attributes. * dmaengine, unwrap use of iio_buffer_set_attrs() * Drop iio_buffer_set_attrs() * Centralize ioctl call handling. Later fix to ensure -EINVAL returned if no handler has run. * Fix an issue with IIO_VAL_FRACTIONAL and negative values - doesn't affect any known existing drivers, but will impact a future one. * kernel-doc fix in trigger.h * file-ops ordering cleanup Features * semtech,sx9310 - Add control of hardware gain, proximity thresholds, hysteresis and debounce. - Increase what information on hardware configuration can be provided via DT. Cleanup and minor features * adi,ad5685 - Add of_match_table * adi,ad7292 - Drop pointless spi_set_drvdata() call * adi,ad7298 - Drop platform data and tidy up external reference config. * adi,ad7303 - Drop platform data handling as unused. * adi,ad7768 - Add new label attribute for channels provided from dt. * adi,ad7887 - devm_ usage in probe simplifying remove and error handling. * adi,adis16201 - Drop pointless spi_set_drvdata() call * adi,adis16209 - Drop pointless spi_set_drvdata() call * adi,adis16240 - White space fixup * adi,adxl372 - use new devm_iio_triggered-buffer_setup_ext() * amlogic,meson-saradc - Drop pointless semicolon. * amstaos,tsl2563 - Put back i2c_device_id table as needed for greybus probing. * atmel,at91_adc - Use of_device_get_match_data() instead of open coding it. - Constify some driver data - Add KCONFIG dep on CONFIG_OF and drop of_match_ptr() - Drop platform data as mostly dead code. - Tidy up reference voltage logic * atmel-sama5d2 - Drop a pointless semicolon - Merge buffer and trigger init into a separate function - Use new devm_iio_triggered_buff_setup_ext() * avago,apds9960 - Drop a pointless semicolon * bosch,bmc150 - Drop a pointless semicolon - Use new iio_triggered_buffer_setup_ext() * bosch,bmp280 - Drop a pointless semicolon * fsl,mma8452 - Constification * (google),cros_ec - Use new devm_iio_triggered_buffer_setup_ext() * hid-sensors - Use new iio_triggered_buffer_setup_ext() * ingenic,adc - Drop a pointless semicolon * invensense,icm426xx - Fix MAINTAINERS entry missing : * mediatek,mt6577_audxac - Add binding doc for mt8516 compatible with mt8173 * motorola,cpcap-adc - Fix an implicit fallthrough marking that clang needs to avoid warning. * samsung,exynos-adc - Stop relying on users counter form input device in ISR. * st,lsm6dsx - add vdd and vddio regulator control (including binding update) * st,stm32-adc - Tidy up code for dma transfers. - Adapt clock duty cycle for proper functioning. Note no known problems with existing boards. * st,vl53l0x-i2c - Put back i2c_device_id table as needed for greybus probing. * vishay,vcnl4035 - Put back i2c_device_id table as needed for greybus probing. * tag 'iio-for-5.11a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (126 commits) dt-bindings:iio:adc:x-powers,axp209-adc: txt to yaml conversion dt-bindings:iio:adc:renesas,rcar-gyroadc: txt to yaml conversion. dt-bindings:iio:adc:atmel,sama5d2-adc: txt to yaml conversion dt-bindings:iio:magnetometer:pni,rm3100: txt to yaml conversion. dt-bindings:iio:magnetometer:honeywell,hmc5843: txt to yaml format conversion dt-bindings:iio:magnetometer:bosch,bmc150_magn: txt to yaml conversion. dt-bindings:iio:magnetometer:asahi-kasei,ak8974: txt to yaml format conversion dt-bindings:iio:magnetometer:fsl,mag3110: txt to yaml conversion dt-bindings:iio:light:st,vl6180: txt to yaml format conversion. dt-bindings:iio:light:vishay,vcnl4035: txt to yaml conversion dt-bindings:iio:light:st,uvis25: txt to yaml conversion for this UV sensor dt-bindings:iio:light:upisemi,us51882: txt to yaml conversion. dt-bindings:iio:light:ti,opt3001: txt to yaml conversion dt-bindings:iio:light:maxim,max44009: txt to yaml conversion. dt-bindings:iio:light:sharp,gp2ap020a00f: txt to yaml conversion. dt-bindings:iio:light:capella,cm36651: txt to yaml conversion. dt-bindings:iio:light:avago,apds9960: txt to yaml conversion dt-bindings:iio:light:avago,apds9300: txt to yaml conversion. dt-bindings:iio:imu:st,lsm6dsx: txt to yaml conversion dt-bindings:iio:imu:adi,adis16480: txt to yaml conversion ...
2020-11-21iio: core: return -EINVAL when no ioctl handler has been runAlexandru Ardelean1-0/+3
It seems that when this was tested the happy case was more tested. A few of the userspace apps rely on this returning negative error codes in case an ioctl() is not available. When running multiple ioctl() handlers or when calling an ioctl() that doesn't exist, IIO_IOCTL_UNHANDLED is returned. In that case -EINVAL should be returned. Fixes: 8dedcc3eee3a ("iio: core: centralize ioctl() calls to the main chardev") Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201117095154.7189-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21iio: core: organize buffer file-ops in the order defined in the structAlexandru Ardelean1-4/+4
The change is mostly cosmetic. This organizes the order of assignment of the members of 'iio_buffer_fileops' to be similar to the one as defined in the 'struct file_operations' type. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201117103753.8450-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21iio: accel: adis16209: remove unneeded spi_set_drvdata()Alexandru Ardelean1-1/+0
There is no matching spi_get_drvdata() in the driver. This looks like a left-over from before the driver was converted to device-managed functions. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201119141806.84827-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21iio: accel: adis16201: remove unneeded spi_set_drvdata()Alexandru Ardelean1-1/+0
There is no matching spi_get_drvdata() in the driver. This looks like a left-over from before the driver was converted to device-managed functions. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201119141729.84185-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21iio: adc: ad7292: remove unneeded spi_set_drvdata()Alexandru Ardelean1-2/+0
This seems to have been copied from a driver that calls spi_set_drvdata() but doesn't call spi_get_drvdata(). Setting a private object on the SPI device's object isn't necessary if it won't be accessed. This change removes the spi_set_drvdata() call. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Tested-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Link: https://lore.kernel.org/r/20201119142720.86326-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21iio: adc: cpcap: Fix fall-through warnings for ClangGustavo A. R. Silva1-0/+1
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://github.com/KSPP/linux/issues/115 Link: https://lore.kernel.org/r/b3c1c3f9c76f2f0e832f956587f227e44af57d3d.1605896060.git.gustavoars@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21iio: buffer: remove iio_buffer_set_attrs() helperAlexandru Ardelean1-12/+0
The iio_buffer_set_attrs() is no longer used in the drivers, so it can be removed now. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200929125949.69934-10-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21iio: hid-sensors: use iio_triggered_buffer_setup_ext()Alexandru Ardelean1-13/+9
This change switches to the new iio_triggered_buffer_setup_ext() function and removes the iio_buffer_set_attrs() call, for assigning the HW FIFO attributes to the buffer. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200929125949.69934-9-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21iio: cros_ec: use devm_iio_triggered_buffer_setup_ext()Alexandru Ardelean1-6/+9
This change switches to the new devm_iio_triggered_buffer_setup_ext() function and removes the iio_buffer_set_attrs() call, for assigning the HW FIFO attributes to the buffer. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200929125949.69934-8-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-20 05:25:08 +0000