summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2021-10-19Merge branch 'timers/drivers/armv8.6_arch_timer' into timers/drivers/nextDaniel Lezcano
The branch is a stable branch shared with ARM maintainers for the first 13th patches of the series: It is based on v5.14-rc3. As stated by the changelog: " [... ] enabling ARMv8.6 support for timer subsystem, and was prompted by a discussion with Oliver around the fact that an ARMv8.6 implementation must have a 1GHz counter, which leads to a number of things to break in the timer code: - the counter rollover can come pretty quickly as we only advertise a 56bit counter, - the maximum timer delta can be remarkably small, as we use the countdown interface which is limited to 32bit... Thankfully, there is a way out: we can compute the minimal width of the counter based on the guarantees that the architecture gives us, and we can use the 64bit comparator interface instead of the countdown to program the timer. Finally, we start making use of the ARMv8.6 ECV features by switching accesses to the counters to a self-synchronising register, removing the need for an ISB. Hopefully, implementations will *not* just stick an invisible ISB there... A side effect of the switch to CVAL is that XGene-1 breaks. I have added a workaround to keep it alive. I have added Oliver's original patch[0] to the series and tweaked a couple of things. Blame me if I broke anything. The whole things has been tested on Juno (sysreg + MMIO timers), XGene-1 (broken sysreg timers), FVP (FEAT_ECV, CNT*CTSS_EL0). " Link: https://lore.kernel.org/r/20211017124225.3018098-1-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2021-10-19drm/i915: Remove memory frequency calculationJosé Roberto de Souza
This memory frequency calculated is only used to check if it is zero, what is not useful as it will never actually be zero. Also the calculation is wrong, we should be checking other bit to select the appropriate frequency multiplier while this code is stuck with a fixed multiplier. So here dropping it as whole. v2: - Also remove memory frequency calculation for gen9 LP platforms Cc: Yakui Zhao <yakui.zhao@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 5d0c938ec9cc ("drm/i915/gen11+: Only load DRAM information from pcode") Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211013010046.91858-1-jose.souza@intel.com (cherry picked from commit 83f52364b15265aec47d07e02b0fbf4093ab8554) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-10-19counter/counter-sysfs: use sysfs_emit everywhereDavid Lechner
In the counter subsystem, we are already using sysfs_emit(), but there were a few places where we were still using sprintf() in *_show() functions. For consistency and added protections, use sysfs_emit() everywhere. Suggested-by: Greg KH <gregkh@linuxfoundation.org> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: David Lechner <david@lechnology.com> Link: https://lore.kernel.org/r/20211017190106.3472645-1-david@lechnology.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-19char: xillybus: fix msg_ep UAF in xillyusb_probe()Ziyang Xuan
When endpoint_alloc() return failed in xillyusb_setup_base_eps(), 'xdev->msg_ep' will be freed but not set to NULL. That lets program enter fail handling to cleanup_dev() in xillyusb_probe(). Check for 'xdev->msg_ep' is invalid in cleanup_dev() because 'xdev->msg_ep' did not set to NULL when was freed. So the UAF problem for 'xdev->msg_ep' is triggered. ================================================================== BUG: KASAN: use-after-free in fifo_mem_release+0x1f4/0x210 CPU: 0 PID: 166 Comm: kworker/0:2 Not tainted 5.15.0-rc5+ #19 Call Trace: dump_stack_lvl+0xe2/0x152 print_address_description.constprop.0+0x21/0x140 ? fifo_mem_release+0x1f4/0x210 kasan_report.cold+0x7f/0x11b ? xillyusb_probe+0x530/0x700 ? fifo_mem_release+0x1f4/0x210 fifo_mem_release+0x1f4/0x210 ? __sanitizer_cov_trace_pc+0x1d/0x50 endpoint_dealloc+0x35/0x2b0 cleanup_dev+0x90/0x120 xillyusb_probe+0x59a/0x700 ... Freed by task 166: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x109/0x140 kfree+0x117/0x4c0 xillyusb_probe+0x606/0x700 Set 'xdev->msg_ep' to NULL after being freed in xillyusb_setup_base_eps() to fix the UAF problem. Fixes: a53d1202aef1 ("char: xillybus: Add driver for XillyUSB (Xillybus variant for USB)") Cc: stable <stable@vger.kernel.org> Acked-by: Eli Billauer <eli.billauer@gmail.com> Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com> Link: https://lore.kernel.org/r/20211016052047.1611983-1-william.xuanziyang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-19binder: don't detect sender/target during buffer cleanupTodd Kjos
When freeing txn buffers, binder_transaction_buffer_release() attempts to detect whether the current context is the target by comparing current->group_leader to proc->tsk. This is an unreliable test. Instead explicitly pass an 'is_failure' boolean. Detecting the sender was being used as a way to tell if the transaction failed to be sent. When cleaning up after failing to send a transaction, there is no need to close the fds associated with a BINDER_TYPE_FDA object. Now 'is_failure' can be used to accurately detect this case. Fixes: 44d8047f1d87 ("binder: use standard functions to allocate fds") Cc: stable <stable@vger.kernel.org> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Todd Kjos <tkjos@google.com> Link: https://lore.kernel.org/r/20211015233811.3532235-1-tkjos@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-19Merge tag 'misc-habanalabs-next-2021-10-18' of ↵Greg Kroah-Hartman
https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into char-misc-next Oded writes: This tag contains habanalabs driver changes for v5.16: - Add a new uAPI (under the memory ioctl) to request from the driver to export a DMA-BUF object that represents a memory region on the device's DRAM. This is needed to enable peer-to-peer over PCIe between habana device and an RDMA adapter (e.g. mlnx5 or efa rdma adapter). - Add debugfs node to dynamically configure CS timeout. Up until now, it was only configurable through kernel module parameter. - Fetch more comprehensive power information from the firmware. - Always take timestamp when waiting for user interrupt, as the user needs that information to optimize the graph runtime compilation. - Modify user interrupt to look on 64-bit user value as fence, instead of 32-bit. - Bypass reset in case of repeated h/w error event after device reset. This is to prevent endless loop of resets to the device. - Fix several bugs in multi CS completion code. - Fix race condition in fd close/open. - Update to latest firmware headers - Add select CRC32 in kconfig - Small fixes, cosmetics * tag 'misc-habanalabs-next-2021-10-18' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux: (25 commits) habanalabs: refactor fence handling in hl_cs_poll_fences habanalabs: context cleanup cosmetics habanalabs: simplify wait for interrupt with timestamp flow habanalabs: initialize hpriv fields before adding new node habanalabs: Unify frequency set/get functionality habanalabs: select CRC32 habanalabs: add support for dma-buf exporter habanalabs: define uAPI to export FD for DMA-BUF habanalabs: fix NULL pointer dereference habanalabs: fix race condition in multi CS completion habanalabs: use only u32 habanalabs: update firmware files habanalabs: bypass reset for continuous h/w error event habanalabs: take timestamp on wait for interrupt habanalabs: prevent race between fd close/open habanalabs: refactor reset log message habanalabs: define soft-reset as inference op habanalabs: fix debugfs device memory MMU VA translation habanalabs: add support for a long interrupt target value habanalabs: remove redundant cs validity checks ...
2021-10-19staging: r8188eu: Remove redundant 'if' statementFabio M. De Francesco
Remove the redundant first 'if' statement of two identical ones. In rtw_cmd_thread() there are two identical 'if' statement, one immediately after the other. They check whether or not the device is removed or the driver is stopped and, if true, they break a 'while' loop. The only noteworthy context difference is that the second statement is within a block labelled "_next". The code has a 'goto' to the "_next" label so that the checking is performed each time the above directive is encountered. Instead, the first 'if' is before the "_next" label. One of the two must be removed and that it must be the one before the label because "bSurpriseRemoved" as well as "bDriverStopped" may be changed asynchronously by other code of the driver and so they should be checked at each jump to "_next". Tested with "ASUSTek Computer, Inc. Realtek 8188EUS [USB-N10 Nano]". Acked-by: Martin Kaiser <martin@kaiser.cx> Acked-by: Phillip Potter <phil@philpotter.co.uk> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20211018162006.5527-4-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-19staging: r8188eu: Use completions for signaling enqueueingFabio M. De Francesco
rtw_enqueue_cmd() uses a semaphore to notify rtw_cmd_thread() that it has enqueued commands. rtw_cmd_thread() "down(s)" in interruptible mode to wait to be notified. Use completion variables because they are better suited for the purpose. In rtw_cmd_thread(), wait in uninterruptible mode, even if the original code uses down_interruptible(), because the interruption of rtw_cmd_thread() is not allowed and unwanted. Tested with "ASUSTek Computer, Inc. Realtek 8188EUS [USB-N10 Nano]". Acked-by: Phillip Potter <phil@philpotter.co.uk> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20211018162006.5527-3-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-19staging: r8188eu: Use completions for signaling start / end kthreadFabio M. De Francesco
rtw_cmd_thread() "up(s)" a semaphore twice, first to notify callers when its execution is started and then to notify when it is about to end. It makes the same semaphore go "up" twice in the same thread. This construct makes Smatch to warn of duplicate "up(s)". This thread uses interruptible semaphores where instead completions are more suitable. For this purpose it calls an helper (_rtw_down_sema()) that returns values that are never checked. It may lead to bugs. To address the above-mentioned issues, use two completions variables instead of semaphores. Use the uninterruptible versions of wake_for_completion*() because the interruptible / killable versions are not necessary. Tested with "ASUSTek Computer, Inc. Realtek 8188EUS [USB-N10 Nano]". Acked-by: Phillip Potter <phil@philpotter.co.uk> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20211018162006.5527-2-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-19staging: r8188eu: fix a gcc warningMichael Straube
Replace strncpy with strlcpy to fix the following gcc warning. drivers/staging/r8188eu/os_dep/ioctl_linux.c: In function 'rtw_wx_set_enc_ext': drivers/staging/r8188eu/os_dep/ioctl_linux.c:1929:9: warning: 'strncpy' specified bound 16 equals destination size [-Wstringop-truncation] 1929 | strncpy((char *)param->u.crypt.alg, alg_name, IEEE_CRYPT_ALG_NAME_LEN); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The destination buffer size is IEEE_CRYPT_ALG_NAME_LEN and the length of the string to copy is always < IEEE_CRYPT_ALG_NAME_LEN. So strlcpy will never truncate the string. Acked-by: Phillip Potter <phil@philpotter.co.uk> Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20211018221231.7837-1-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-19staging: mt7621-dts: get rid of nodes with no in-tree driverSergio Paracuellos
Nodes for 'i2s' and 'nand' have no driver present inside the linux tree. The normal approach for a dts file to be mainlined is start with those stuff which is already mainlined and get rid of the other stuff. If needed it will be properly added afterwards together with the suitable device driver. Hence, remove both nodes from the device tree include file. Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://lore.kernel.org/r/20211018170206.11959-1-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-19iio: imx8qxp-adc: mark PM functions as __maybe_unusedArnd Bergmann
Without CONFIG_PM_SLEEP, the runtime suspend/resume functions are unused, producing a warning: drivers/iio/adc/imx8qxp-adc.c:433:12: error: 'imx8qxp_adc_runtime_resume' defined but not used [-Werror=unused-function] 433 | static int imx8qxp_adc_runtime_resume(struct device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/iio/adc/imx8qxp-adc.c:419:12: error: 'imx8qxp_adc_runtime_suspend' defined but not used [-Werror=unused-function] 419 | static int imx8qxp_adc_runtime_suspend(struct device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark them as __maybe_unused to shut up the compiler. Fixes: 1e23dcaa1a9f ("iio: imx8qxp-adc: Add driver support for NXP IMX8QXP ADC") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20211013144338.2261316-1-arnd@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: pressure: ms5611: Make ms5611_remove() return voidUwe Kleine-König
Up to now ms5611_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-16-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: potentiometer: max5487: Don't return an error in .remove()Uwe Kleine-König
The only effect of returning an error in an spi .remove() callback is that the spi core issues a generic warning message. Instead emit a more specific error message and return 0 to not report the same issue twice. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-15-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: magn: hmc5843: Make hmc5843_common_remove() return voidUwe Kleine-König
Up to now hmc5843_common_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-14-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: health: afe4403: Don't return an error in .remove()Uwe Kleine-König
The only effect of returning an error in an spi .remove() callback is that the spi core issues another warning message. Don't report the same problem twice and return 0 unconditionally instead. Also degrade the log level to warning, as nothing really bad is expected from a failure to put the device in suspend mode. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-12-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: dac: ad5686: Make ad5686_remove() return voidUwe Kleine-König
Up to now ad5686_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-11-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: dac: ad5592r: Make ad5592r_remove() return voidUwe Kleine-König
Up to now ad5592r_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-10-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: dac: ad5446: Make ad5446_remove() return voidUwe Kleine-König
Up to now ad5446_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-9-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: dac: ad5380: Make ad5380_remove() return voidUwe Kleine-König
Up to now ad5380_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-8-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: mma7455: Make mma7455_core_remove() return voidUwe Kleine-König
Up to now mma7455_core_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-6-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: kxsd9: Make kxsd9_common_remove() return voidUwe Kleine-König
Up to now kxsd9_common_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-5-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: bmi088: Make bmi088_accel_core_remove() return voidUwe Kleine-König
Up to now bmi088_accel_core_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-4-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: bmc150: Make bmc150_accel_core_remove() return voidUwe Kleine-König
Up to now bmc150_accel_core_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-3-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: bma400: Make bma400_remove() return voidUwe Kleine-König
When an i2c or spi driver's remove function returns a non-zero error code nothing happens apart from emitting a generic error message. Make this error message more device specific and return zero instead in the remove callbacks. As the return value of bma400_remove() is unused then, change the function to not yield a return value. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-2-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19drivers:iio:dac:ad5766.c: Add trigger bufferMihail Chindris
This chip is able to generate waveform and using an with the output trigger buffer will be easy to generate one. Signed-off-by: Mihail Chindris <mihail.chindris@analog.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211007080035.2531-7-mihail.chindris@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: triggered-buffer: extend support to configure output buffersAlexandru Ardelean
Now that output (kfifo) buffers are supported, we need to extend the {devm_}iio_triggered_buffer_setup_ext() parameter list to take a direction parameter. This allows us to attach an output triggered buffer to a DAC device. Unfortunately it's a bit difficult to add another macro to avoid changing 5 drivers where {devm_}iio_triggered_buffer_setup_ext() is used. Well, it's doable, but may not be worth the trouble vs just updating all these 5 drivers. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Mihail Chindris <mihail.chindris@analog.com> Link: https://lore.kernel.org/r/20211007080035.2531-4-mihail.chindris@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: kfifo-buffer: Add output buffer supportLars-Peter Clausen
Add output buffer support to the kfifo buffer implementation. The implementation is straight forward and mostly just wraps the kfifo API to provide the required operations. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Mihail Chindris <mihail.chindris@analog.com> Link: https://lore.kernel.org/r/20211007080035.2531-3-mihail.chindris@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: Add output buffer supportMihail Chindris
Currently IIO only supports buffer mode for capture devices like ADCs. Add support for buffered mode for output devices like DACs. The output buffer implementation is analogous to the input buffer implementation. Instead of using read() to get data from the buffer write() is used to copy data into the buffer. poll() with POLLOUT will wakeup if there is space available. Drivers can remove data from a buffer using iio_pop_from_buffer(), the function can e.g. called from a trigger handler to write the data to hardware. A buffer can only be either a output buffer or an input, but not both. So, for a device that has an ADC and DAC path, this will mean 2 IIO buffers (one for each direction). The direction of the buffer is decided by the new direction field of the iio_buffer struct and should be set after allocating and before registering it. Co-developed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Co-developed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Mihail Chindris <mihail.chindris@analog.com> Link: https://lore.kernel.org/r/20211007080035.2531-2-mihail.chindris@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19drivers: iio: chemical: Add support for Sensirion SCD4x CO2 sensorRoan van Dijk
This is a driver for the SCD4x CO2 sensor from Sensirion. The sensor is able to measure CO2 concentration, temperature and relative humdity. The sensor uses a photoacoustic principle for measuring CO2 concentration. An I2C interface is supported by this driver in order to communicate with the sensor. Signed-off-by: Roan van Dijk <roan@protonic.nl> Link: https://lore.kernel.org/r/20211008101706.755942-4-roan@protonic.nl Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: light: noa1305: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928014156.1491-4-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: light: cm36651: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928014156.1491-2-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: health: afe4404: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928014403.1563-2-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: health: afe4403: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928014403.1563-1-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: st_lsm9ds0: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928014055.1431-2-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: st_sensors: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928014055.1431-1-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: dac: ti-dac7311: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928013902.1341-8-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: dac: stm32-dac: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928013902.1341-7-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: dac: mcp4922: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928013902.1341-6-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: dac: max5821: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928013902.1341-5-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: dac: ds4424: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928013902.1341-4-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: dac: ltc1660: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://lore.kernel.org/r/20210928013902.1341-3-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: dac: lpc18xx_dac: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928013902.1341-2-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: dac: ad8801: Make use of the helper function dev_err_probe()Cai Huoqing
When possible use dev_err_probe help to properly deal with the PROBE_DEFER error, the benefit is that DEFER issue will be logged in the devices_deferred debugfs file. Using dev_err_probe() can reduce code size, and the error value gets printed. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210928013902.1341-1-caihuoqing@baidu.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: ad799x: Implement selecting external reference voltage input on ↵Florian Boor
AD7991, AD7995 and AD7999. Make use of the AD7991_REF_SEL bit and support using the external reference voltage if 'vref-supply' is present. Use VCC voltage supply as reference if no extra reference is supplied. Signed-off-by: Florian Boor <florian.boor@kernelconcepts.de> Link: https://lore.kernel.org/r/20210930104249.2924336-1-florian.boor@kernelconcepts.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: adc: max1027: fix error code in max1027_wait_eoc()Dan Carpenter
Return -ETIMEDOUT on timeout instead of success. Fixes: 1f7b4048b31b ("iio: adc: max1027: Use the EOC IRQ when populated for single reads") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: imu: adis16400: Fix buffer alignment requirements.Jonathan Cameron
iio_push_to_buffers_with_timestamp() requires that the buffer is 8 byte alignment to ensure an inserted timestamp is naturally aligned. This requirement was not met here when burst mode is in use beause of a leading u16. Use the new iio_push_to_buffers_with_ts_unaligned() function that has more relaxed requirements. It is somewhat complex to access that actual data length, but a safe bound can be found by using scan_bytes - sizeof(timestamp) so that is used in this path. More efficient approaches exist, but this ensure correctness at the cost of using a bounce buffer. Fixes: 5075e0720d93 ("iio: imu: adis: generalize burst mode support") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210613151039.569883-5-jic23@kernel.org
2021-10-19iio: gyro: mpu3050: Fix alignment and size issues with buffers.Jonathan Cameron
Fix a set of closely related issues. 1. When using fifo_values() there was not enough space for the timestamp to be inserted by iio_push_to_buffers_with_timestamp() 2. fifo_values() did not meet the alignment requirement of iio_push_to_buffers_with_timestamp() 3. hw_values did not meet the alignment requirement either. 1 and 2 fixed by using new iio_push_to_buffers_with_ts_unaligned() which has no alignment or space padding requirements. 3 fixed by introducing a structure that makes the space and alignment requirements explicit. Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210613151039.569883-4-jic23@kernel.org
2021-10-19iio: adc: ti-adc108s102: Fix alignment of buffer pushed to iio buffers.Jonathan Cameron
Use the newly introduce iio_push_to_buffers_with_ts_unaligned() function to ensure a bounce buffer is used to provide the required alignment and space padding needed by the IIO core which requires the timestamp is naturally aligned. There will be a performance cost to this change but it will ensure the driver works on platforms that do not support unaligned 8 byte assignments, and with consumer drivers that may assume natural alignment of the timestamp. Issue found as part of an audit of all calls to iio_push_to_buffers_with_timestamp() Fixes: 7e87d11c9bda ("iio: adc: Add support for TI ADC108S102 and ADC128S102") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Link: https://lore.kernel.org/r/20210613151039.569883-3-jic23@kernel.org
2021-10-19iio: core: Introduce iio_push_to_buffers_with_ts_unaligned()Jonathan Cameron
Whilst it is almost always possible to arrange for scan data to be read directly into a buffer that is suitable for passing to iio_push_to_buffers_with_timestamp(), there are a few places where leading data needs to be skipped over. For these cases introduce a function that will allocate an appropriate sized and aligned bounce buffer (if not already allocated) and copy the unaligned data into that before calling iio_push_to_buffers_with_timestamp() on the bounce buffer. We tie the lifespace of this buffer to that of the iio_dev.dev which should ensure no memory leaks occur. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210613151039.569883-2-jic23@kernel.org