summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
| * Staging: rtl8723bs/core: delete empty if statementBrother Matthew De Angelis2020-12-071-3/+0
| | | | | | | | | | | | | | | | | | | | Delete an if statement that was not executing anything when true. This has the side effect of removing one checkpatch warning about braces not being necessary. Signed-off-by: Brother Matthew De Angelis <matthew.v.deangelis@gmail.com> Link: https://lore.kernel.org/r/1895dc8a7b44bfdcb6a46273703fabad80cbdf99.1607209336.git.matthew.v.deangelis@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * staging: bcm2835: fix vchiq_mmal dependenciesArnd Bergmann2020-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the MMAL code is built-in but the vchiq core config is set to =m, the mmal code never gets built, which in turn can lead to link errors: ERROR: modpost: "vchiq_mmal_port_set_format" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_port_disable" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_port_parameter_set" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_component_finalise" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_port_connect_tunnel" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_component_enable" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_finalise" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_component_init" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_component_disable" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "mmal_vchi_buffer_init" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_port_enable" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_version" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_submit_buffer" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_init" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "mmal_vchi_buffer_cleanup" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_port_parameter_get" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! Change the Kconfig to depend on BCM2835_VCHIQ like the other drivers, and remove the now redundant dependencies. Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera") Acked-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20201203223836.1362313-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Staging: rtl8723bs/core fix brace coding style issues in rtw_ioctl_set.cBrother Matthew De Angelis2020-12-041-23/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix all the brace code style warnings found by the checkpatch tool at the following lines: rtw_ioctl_set.c:178: WARNING: braces {} are not necessary for any arm of this statement rtw_ioctl_set.c:219: WARNING: braces {} are not necessary for any arm of this statement rtw_ioctl_set.c:255: WARNING: braces {} are not necessary for any arm of this statement rtw_ioctl_set.c:324: WARNING: braces {} are not necessary for any arm of this statement rtw_ioctl_set.c:372: WARNING: braces {} are not necessary for any arm of this statement rtw_ioctl_set.c:396: WARNING: braces {} are not necessary for any arm of this statement rtw_ioctl_set.c:441: WARNING: braces {} are not necessary for single statement blocks rtw_ioctl_set.c:527: WARNING: braces {} are not necessary for any arm of this statement Signed-off-by: Brother Matthew De Angelis <matthew.v.deangelis@gmail.com> Link: https://lore.kernel.org/r/20201203025836.GA420974@a Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Merge tag 'iio-for-5.11b-take2' of ↵Greg Kroah-Hartman2020-12-03107-2373/+3014
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: 2nd set of IIO device support, features, cleanups and yaml conversions for 5.11 v2: Fix some missing Sign offs from me that Greg found in v1. Includes low priority/late breaking/long standing bug fixes. Note this includes the last few patches that were listed in the description for the previous pull request but weren't actually in the PULL. New devices support * bosch,bmc150-accel - Support for BMA222, including adding binding doc that was previously missing. * st,lsm6dsx - Support LSM6DSOP accelerometer + gyroscope sensor. yaml-conversions by manufacturer * core - adc - iio-binding (drop as now in dt-schema) - temperature (drop as not clear it is generic) * generic (no specific manufacturer) - dpot-dac - current-sense-amplifier - current-sense-shunt - envelope-detector - voltage-divider * adi,ad5592r adi,ad7124 adi,ad7292 adi,adf4350 * atmel,sama9260-adc * bosch,bma180 bosch,bmg180 * brcm,iproc-static-adc * capella,cm3605 * fsl,mma8452 * kionix,kxcjk1013 * maxim,max1027 (from trivial) * mediatek,mt2701-auxdac * microchip,mcp4531 (from trivial) * qcom,pm8018-adc qcom,spi-iadc * st,st-sensors * ti,ads124s08 ti,afe4403 ti,afe4404 ti,lmp91000 ti,palmas-gpadc Features * bosch,bmc150 - Handle unusual ACPI binding where two devices are provided in a single ACPI device (BOSC0200). - ACPI based mount matrix handling * st,hts221 - regulator control * st,lsm6dsx - regulator control Cleanup + minor fixes * core - Reduce duplication in iio_format_avail_{list,range}() and iio_format_list() - Fix an issue in the demux update code that could lead to misaligned data. Possible no existing driver hits this. Been there a very long time with no bug reports. - Improve iio_map_array_register() error handling. - Avoid polling driver again if try_reenable() callback returns non 0. Only users of this were bugs so also drop the return value. * core/cb_buffer - Return an error if no callback provided (include adding a dummy for one unusual case where no callback is valid). * trigger/hrtimer-trig, sysfs-trig - Fix an issue seen with PREEMPT_RT by marking irq_work as expiring in hard interrupt context. * adi,ad_sigma_delta library - Avoid putting SPI transfer buffers on stack for DMA safety reasons * adi,ad5272 - Fix discrepancy in polarity of reset line between binding documentation (which was right) and driver. * adi,ad7298 - Use devm for all of probe * atmel,at91_adc - Drop at91_adc_ids as only support DT probe - Simplify resolution selection and bindings - Drop binding for triggers and move into driver based on compatible. - Merge at91_adc_probe_dt() into main at91_adc_probe() * bosch,bmc150 - Drop unused structure member. * bosch,bmi160 - Fix overly long buffer due to wrong channel count. - Fix potential buffer alignment into iio_push_to_buffers_with_timestamp() * fsl,mag3110 - Fix potential buffer alignment into iio_push_to_buffers_with_timestamp() * fsl,mpl3115 - Fix potential buffer alignment into iio_push_to_buffers_with_timestamp() * invn,mpu3050 - Use 64 bit local variable and FIELD_GET to simplify code that extracts values from OTP. * qcom,spmi-vadc - Drop wrong use of io-channel-ranges in binding doc. * rockchip,saradc - Fix a missing clk_disable_unprepare() in an error path. * rohm,rpr0521 - Fix potential buffer alignment into iio_push_to_buffers_with_timestamp() * samsung,exynos-adc - Drop wrong use of io-channel-ranges in binding doc. * st,lsm6dsx - Reduce duplication in the chip model specific tables. - Fix an issue with missed edge-interrupts that can occur when using the FIFO. * st,uvis21 - Fix potential buffer alignment into iio_push_to_buffers_with_timestamp() * ti,adc084s021 - Tidy up endian types to clear a warning. * ti,ads124s08 - Fix too long a buffer. - Fix potential buffer alignment into iio_push_to_buffers_with_timestamp() Counter * microchip,tcb-counter - Add Kamel Bouhara to MAINTAINERS - Fix CMR value check * tag 'iio-for-5.11b-take2' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (80 commits) iio: adc: rockchip_saradc: fix missing clk_disable_unprepare() on error in rockchip_saradc_resume iio: imu: st_lsm6dsx: fix edge-trigger interrupts counter: microchip-tcb-capture: Fix CMR value check iio: sysfs-trigger: Mark irq_work to expire in hardirq context iio: hrtimer-trigger: Mark hrtimer to expire in hard interrupt context iio: accel: bmc150: Get mount-matrix from ACPI iio: accel: bmc150: Check for a second ACPI device for BOSC0200 iio: accel: bmc150: Removed unused bmc150_accel_dat irq member iio:gyro:mpu3050 Treat otp value as a __le64 and use FIELD_GET() to break up iio:adc:ti-ads124s08: Fix alignment and data leak issues. iio:adc:ti-ads124s08: Fix buffer being too long. iio:pressure:mpl3115: Force alignment of buffer iio:imu:bmi160: Fix alignment and data leak issues iio:imu:bmi160: Fix too large a buffer. iio:magnetometer:mag3110: Fix alignment and data leak issues. iio:light:st_uvis25: Fix timestamp alignment and prevent data leak. iio:light:rpr0521: Fix timestamp alignment and prevent data leak. iio:adc:ti-adc084s021 Tidy up endian types iio:trigger: rename try_reenable() to reenable() plus return void iio: Fix: Do not poll the driver again if try_reenable() callback returns non 0. ...
| | * iio: adc: rockchip_saradc: fix missing clk_disable_unprepare() on error in ↵Qinglang Miao2020-12-031-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>
| | * iio: imu: st_lsm6dsx: fix edge-trigger interruptsLorenzo Bianconi2020-12-031-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>
| | * counter: microchip-tcb-capture: Fix CMR value checkWilliam Breathitt Gray2020-12-031-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ATMEL_TC_ETRGEDG_* defines are not masks but rather possible values for CMR. This patch fixes the action_get() callback to properly check for these values rather than mask them. Fixes: 106b104137fd ("counter: Add microchip TCB capture counter") Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Kamel Bouhara <kamel.bouhara@bootlin.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201114232805.253108-1-vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
| | * iio: sysfs-trigger: Mark irq_work to expire in hardirq contextLars-Peter Clausen2020-12-031-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>
| | * iio: hrtimer-trigger: Mark hrtimer to expire in hard interrupt contextLars-Peter Clausen2020-12-031-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>
| | * iio: accel: bmc150: Get mount-matrix from ACPIHans de Goede2020-12-031-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>
| | * iio: accel: bmc150: Check for a second ACPI device for BOSC0200Jeremy Cline2020-12-033-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>
| | * iio: accel: bmc150: Removed unused bmc150_accel_dat irq memberHans de Goede2020-12-031-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>
| | * iio:gyro:mpu3050 Treat otp value as a __le64 and use FIELD_GET() to break upJonathan Cameron2020-12-031-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
| | * iio:adc:ti-ads124s08: Fix alignment and data leak issues.Jonathan Cameron2020-12-031-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
| | * iio:adc:ti-ads124s08: Fix buffer being too long.Jonathan Cameron2020-12-031-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
| | * iio:pressure:mpl3115: Force alignment of bufferJonathan Cameron2020-12-031-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
| | * iio:imu:bmi160: Fix alignment and data leak issuesJonathan Cameron2020-12-032-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
| | * iio:imu:bmi160: Fix too large a buffer.Jonathan Cameron2020-12-031-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
| | * iio:magnetometer:mag3110: Fix alignment and data leak issues.Jonathan Cameron2020-12-031-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
| | * iio:light:st_uvis25: Fix timestamp alignment and prevent data leak.Jonathan Cameron2020-12-032-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
| | * iio:light:rpr0521: Fix timestamp alignment and prevent data leak.Jonathan Cameron2020-12-031-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
| | * iio:adc:ti-adc084s021 Tidy up endian typesJonathan Cameron2020-12-031-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
| | * iio:trigger: rename try_reenable() to reenable() plus return voidJonathan Cameron2020-12-0311-61/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| | * iio: Fix: Do not poll the driver again if try_reenable() callback returns non 0.Jonathan Cameron2020-12-031-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
| | * io:core: In iio_map_array_register() cleanup in case of errorLino Sanfilippo2020-12-031-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>
| | * iio:core: Introduce unlocked version of iio_map_array_unregister()Lino Sanfilippo2020-12-031-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>
| | * dt-bindings: iio: imu: st_lsm6dsx: add lsm6dsop device bindingsLorenzo Bianconi2020-12-031-0/+1
| | | | | | | | | | | | | | | | | | Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/501ff8187d2df584ec978c7e7ec5c445c3d0741c.1606642528.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
| | * iio: imu: st_lsm6dsx: add support to LSM6DSOPLorenzo Bianconi2020-12-036-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>
| | * iio: imu: st_lsmdsx: compact st_lsm6dsx_sensor_settings tableLorenzo Bianconi2020-12-032-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>
| | * iio: adc: at91_adc: merge at91_adc_probe_dt back in at91_adc_probeAlexandre Belloni2020-12-031-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>
| | * dt-bindings:iio:adc:remove triggersAlexandre Belloni2020-12-031-46/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The trigger child nodes are not necessary anymore as they are defined directly by the driver, depending on the compatible string. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Rob Herring <robh+dt@kernel.org> Link: https://lore.kernel.org/r/20201128222818.1910764-7-alexandre.belloni@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
| | * iio: adc: at91_adc: rework trigger definitionAlexandre Belloni2020-12-031-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>
| | * dt-bindings:iio:adc:atmel, sama9260-adc: conversion to yaml from at91_adc.txtJonathan Cameron2020-12-032-78/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a few things we would do differently in an ADC binding if we were starting from scratch but we are stuck with what we have (which made sense back when this was written!) We may be able to tighten up some elements of this binding in the future by careful checking of what values properties can actually take. Note the unusual sign off chain is representative of the path this patch took. Jonathan wrote the patch, which was then included in a series by Alexandre and ultimately applied by Jonathan. [Alexandre Belloni: add sama5d3, remove atmel,adc-res and atmel,adc-res-names] Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20201128222818.1910764-5-alexandre.belloni@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
| | * dt-bindings:iio:adc:remove atmel, adc-res and atmel, adc-res-namesAlexandre Belloni2020-12-031-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove atmel,adc-res and atmel,adc-res-names as they are not necessary and are handled by the driver. Also add sama5d3 to the list of possible chips. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Rob Herring <robh+dt@kernel.org> Link: https://lore.kernel.org/r/20201128222818.1910764-4-alexandre.belloni@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
| | * iio: adc: at91_adc: rework resolution selectionAlexandre Belloni2020-12-031-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>
| | * iio: adc: at91_adc: remove at91_adc_idsAlexandre Belloni2020-12-031-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>
| | * dt-bindings:iio:potentiostat:ti,lmp91000: txt to yaml conversion.Jonathan Cameron2020-12-032-33/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were a few parts of the example that did not conform to the binding description and would not have worked with the Linux driver as a result. Fixed them whilst doing this conversion. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Link: https://lore.kernel.org/r/20201031181242.742301-11-jic23@kernel.org
| | * dt-bindings:iio:light:capella,cm3605: txt to yaml conversion.Jonathan Cameron2020-12-032-41/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simple conversion using the new iio-consumers.yaml binding in the dt-schema. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201031181242.742301-10-jic23@kernel.org
| | * dt-bindings:iio:afe:voltage-divider: txt to yaml conversionJonathan Cameron2020-12-032-53/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simple binding so straight forward conversion, though did require adding a separate binding document for the max1027 to reflect its abilities to provide channels to consumers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20201031181242.742301-9-jic23@kernel.org
| | * dt-bindings:iio:adc:maxim,max1027: Pull out to separate binding doc.Jonathan Cameron2020-12-032-12/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The afe/voltage-divider.yaml example uses this device with 2 properties not provided by trivial-devices.yaml (spi-max-frequency and #io-channel-cells) Solve that by creating a more specific binding doc. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Philippe Reynes <tremyfr@yahoo.fr> Link: https://lore.kernel.org/r/20201031181242.742301-8-jic23@kernel.org
| | * dt-bindings:iio:afe:current-sense-shunt: txt to yaml conversion.Jonathan Cameron2020-12-032-41/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | Very simple binding. As such straight forward conversion. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20201031181242.742301-7-jic23@kernel.org
| | * dt-bindings:iio:afe:current-sense-amplifier: txt to yaml conversion.Jonathan Cameron2020-12-032-26/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note this includes a fix in the example where we had *-mul instead of *-mult. The binding doc and driver agree that it should be *-mult Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20201031181242.742301-6-jic23@kernel.org
| | * dt-bindings:iio:adc:envelope-detector: txt to yaml conversion.Jonathan Cameron2020-12-032-54/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Straight forward format conversion. The example in here is fun in that it has 2 separate provider / consumer pairs. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20201031181242.742301-5-jic23@kernel.org
| | * dt-bindings:iio:potentiometer: give microchip,mcp4531 its own bindingJonathan Cameron2020-12-032-128/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We use this part in an example for the envelope detector. That showed that we need to allow for the #io-channel-cells property which trivial-devices.yaml does not. It doesn't make sense to add that property to trivial-devices as it only applies for those devices that can provide some sort of DAC or ADC service to another device driver. Hence solution will be to pull some IIO devices out to have their own file on a case by case basis. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20201031181242.742301-4-jic23@kernel.org
| | * dt-bindings:iio:dac:dpot-dac: yaml conversion.Jonathan Cameron2020-12-032-41/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Txt to yaml format conversion. I dropped the example section describing the measurement ADC, as that isn't strictly part of this binding. Uses the new dt-schema/schema/iio/iio-consumer.yaml schema. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20201031181242.742301-3-jic23@kernel.org
| | * dt-bindings:iio:iio-binding.txt Drop file as content now in dt-schemaJonathan Cameron2020-12-031-102/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | File contained generic IIO wide bindings. Now part of the external dt-schema repository. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201031181242.742301-2-jic23@kernel.org
| | * dt-bindings:iio:adc:adi,ad7292: Use new adc.yaml binding for channels.Jonathan Cameron2020-12-031-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Also add additionalProperties: false for the child nodes. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Link: https://lore.kernel.org/r/20201031182423.742798-4-jic23@kernel.org
| | * dt-bindings:iio:adc:adi,ad7124: Use the new adc.yaml channel bindingJonathan Cameron2020-12-031-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This both ensures this binding is compliant with the generic properties and reduces the amount we need to specify in this separate binding. Whilst here mark the child node as additionalProperties: false Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Link: https://lore.kernel.org/r/20201031182423.742798-3-jic23@kernel.org
| | * dt-bindings:iio:adc: convert adc.txt to yamlJonathan Cameron2020-12-032-29/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each driver that uses this will need to use a $ref We can't always enable it like most of the generic bindings due to channel@X matching far more widely than IIO. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201031182423.742798-2-jic23@kernel.org
| | * dt-bindings:iio:health:ti,afe4404: txt to yaml conversionJonathan Cameron2020-12-032-29/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This basically has same questions as for the afe4403. We could combine the two bindings, but as the drivers are separate and it would be a little fiddly due to different buses let's keep the separating. To repeat questions from the ti,afe4403 binding. A few questions came up whilst converting this one. 1) What is actually required? - Checking Linux driver, interrupt is not, and the tx-supply could be supplied by a stub regulator as long as it's always on. As such I have reduced the required list to just compatible and reg. 2) What is the regulator called? - It's tx-supply in the binding doc, but the driver request tx_sup I will shortly send out a fix for the driver to match the binding doc which is the better choice of naming. As Andrew's email is bouncing, I've put myself as temporary maintainer for this binding until someone else steps up. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201031184854.745828-9-jic23@kernel.org
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-20 18:51:13 +0000