- 23 Nov, 2022 38 commits
-
-
Ibrahim Tilki authored
Adding support for max11410 24-bit, 1.9ksps delta-sigma adc which has 3 differential reference and 10 differential channel inputs. Inputs and references can be buffered internally. Inputs can also be amplified with internal PGA. Device has four digital filter modes: FIR50/60, FIR50, FIR60 and SINC4. FIR 50Hz and 60Hz rejections can be enabled/disabled separately. Digital filter selection affects sampling frequency range so driver has to consider the configured filter when configuring sampling frequency. Signed-off-by:
Ibrahim Tilki <Ibrahim.Tilki@analog.com> Link: https://lore.kernel.org/r/20221003105903.229-2-Ibrahim.Tilki@analog.comSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Krzysztof Kozlowski authored
For devices connectable by SPI bus (e.g. already using "spi-max-frequency" property), reference the "spi-peripheral-props.yaml" schema to allow using all SPI device properties, even these which device bindings author did not tried yet. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20221004115642.63749-8-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
For devices connectable by SPI bus (e.g. already using "spi-max-frequency" property), reference the "spi-peripheral-props.yaml" schema to allow using all SPI device properties, even these which device bindings author did not tried yet. Signed-off-by:
-
Krzysztof Kozlowski authored
For devices connectable by SPI bus (e.g. already using "spi-max-frequency" property), reference the "spi-peripheral-props.yaml" schema to allow using all SPI device properties, even these which device bindings author did not tried yet. Signed-off-by:
-
Krzysztof Kozlowski authored
For devices connectable by SPI bus (e.g. already using "spi-max-frequency" property), reference the "spi-peripheral-props.yaml" schema to allow using all SPI device properties, even these which device bindings author did not tried yet. Signed-off-by:
Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20221004115642.63749-5-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
For devices connectable by SPI bus (e.g. already using "spi-max-frequency" property), reference the "spi-peripheral-props.yaml" schema to allow using all SPI device properties, even these which device bindings author did not tried yet. Signed-off-by:
-
Krzysztof Kozlowski authored
For devices connectable by SPI bus (e.g. already using "spi-max-frequency" property), reference the "spi-peripheral-props.yaml" schema to allow using all SPI device properties, even these which device bindings author did not tried yet. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by:
-
Krzysztof Kozlowski authored
Improve example by: dropping unrelated properties (status and cs-gpios) and using generic node name. Signed-off-by:
-
Krzysztof Kozlowski authored
Reference the spi-peripheral-props.yaml schema to allow using all properties typical for SPI-connected devices, even these which device bindings author did not tried yet. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by:
-
Nuno Sá authored
As the maintainer email no longer exists, change it to myself. Signed-off-by:
-
Nuno Sá authored
As the maintainer email no longer exists, change it to myself. Signed-off-by:
-
Nuno Sá authored
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by:
-
Nuno Sá authored
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by:
-
Nuno Sá authored
In order to drop the internal lock usage we needed two different things: 1) The first place where 'mlock' was being used was a typical case where iio_device_claim_direct_mode() fits perfectly. 2) In the second case, it was being used to prevent concurrent accesses to the device and shared data but nothing was being enforced with regards to buffering (i.e, there was nothing preventing from changing the conversion mode while buffering). Hence, in this case, a new lock was introduced in the state structure. Note that the goal is not to introduce any functional change and that is the reason why a new lock was introduced to guarantee 2). While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by:
Haibo Chen <haibo.chen@nxp.com> Link: https://lore.kernel.org/r/20221004134909.1692021-11-nuno.sa@analog.comSigned-off-by:
-
Nuno Sá authored
This is a precursor change to make it simpler to remove the 'mlock' usage. Having the code in it's own helper function, also makes it easier to read the error paths. Signed-off-by:
-
Nuno Sá authored
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by:
-
Nuno Sá authored
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20221004134909.1692021-8-nuno.sa@analog.comSigned-off-by:
-
Nuno Sá authored
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20221004134909.1692021-7-nuno.sa@analog.comSigned-off-by:
-
Nuno Sá authored
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by:
-
Nuno Sá authored
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by:
-
Nuno Sá authored
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by:
-
Nuno Sá authored
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by:
-
Nuno Sá authored
'mlock' was being grabbed when setting the device frequency. In order to not introduce any functional change a new lock is added. With that in mind, the lock also needs to be grabbed in the places where 'mlock' is since it was also being used to protect st->config against the current device state. On the other places the lock was being used, we can just drop it since we are only doing one i2c bus read/write which is already safe. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by:
-
Wei Yongjun authored
SPI devices use the spi_device_id for module autoloading even on systems using device tree, after commit 5fa6863b ("spi: Check we have a spi_device_id for each DT compatible"), kernel warns as follows since the spi_device_id is missing: SPI driver ad7124 has no spi_device_id for adi,ad7124-4 SPI driver ad7124 has no spi_device_id for adi,ad7124-8 Add spi_device_id entries to silence the warnings, and ensure driver module autoloading works. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20220921163620.805879-6-weiyongjun@huaweicloud.comSigned-off-by:
-
Wei Yongjun authored
SPI devices use the spi_device_id for module autoloading even on systems using device tree, after commit 5fa6863b ("spi: Check we have a spi_device_id for each DT compatible"), kernel warns as follows since the spi_device_id is missing: SPI driver ad7192 has no spi_device_id for adi,ad7190 SPI driver ad7192 has no spi_device_id for adi,ad7193 SPI driver ad7192 has no spi_device_id for adi,ad7195 Add spi_device_id entries to silence the warnings, and ensure driver module autoloading works. Signed-off-by:
-
Wei Yongjun authored
SPI devices use the spi_device_id for module autoloading even on systems using device tree, after commit 5fa6863b ("spi: Check we have a spi_device_id for each DT compatible"), kernel warns as follows since the spi_device_id is missing: SPI driver ad9467 has no spi_device_id for adi,ad9265 SPI driver ad9467 has no spi_device_id for adi,ad9434 Add spi_device_id entries to silence the warnings, and ensure driver module autoloading works. Signed-off-by:
-
Wei Yongjun authored
SPI devices use the spi_device_id for module autoloading even on systems using device tree, after commit 5fa6863b ("spi: Check we have a spi_device_id for each DT compatible"), kernel warns as follows since the spi_device_id is missing: SPI driver sca3300 has no spi_device_id for murata,scl3300 Add spi_device_id entries to silence the warning, and ensure driver module autoloading works. Signed-off-by:
Tomas Melin <tomas.melin@vaisala.com> Link: https://lore.kernel.org/r/20220921163620.805879-3-weiyongjun@huaweicloud.comSigned-off-by:
-
Wei Yongjun authored
SPI devices use the spi_device_id for module autoloading even on systems using device tree, after commit 5fa6863b ("spi: Check we have a spi_device_id for each DT compatible"), kernel warns as follows since the spi_device_id is missing: SPI driver ads131e08 has no spi_device_id for ti,ads131e04 SPI driver ads131e08 has no spi_device_id for ti,ads131e06 Add spi_device_id entries to silence the warnings, and ensure driver module autoloading works. Signed-off-by:
-
Yang Yingliang authored
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. It's more simple in error path. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220927064841.319291-1-yangyingliang@huawei.comSigned-off-by:
-
Mårten Lindahl authored
Add read/write attribute for proximity integration time, and read attribute for available proximity integration times for the vcnl4040 chip. Signed-off-by:
Mårten Lindahl <marten.lindahl@axis.com> Link: https://lore.kernel.org/r/20220926091900.1724105-3-marten.lindahl@axis.comSigned-off-by:
-
Mårten Lindahl authored
As the vcnl4040 and vcnl4200 chip uses runtime power management for turning the ambient light and proximity sensors on/off, it overwrites the entire register each time. In ALS_CONF register bit fields ALS_IT, ALS_PERS, ALS_INT_EN are overwritten. In PS_CONF1 register bit fields PS_DUTY, PS_PERS, PS_IT, PS_HD, and PS_INT are overwritten. Add functions for preserving the affected bit fields when changing power state. Signed-off-by:
-
Wei Yongjun authored
ADMV8818_SW_IN_WR0_MSK and ADMV8818_SW_OUT_WR0_MSK have 3 bits, which means a length of 8, but freq_range_hpf and freq_range_lpf array size is 4, may end up reading 4 elements beyond the end of those arrays. Check value first before access freq_range_hpf and freq_range_lpf to harden against the hardware allowing out of range values. Signed-off-by:
Antoniu Miclaus <antoniu.miclaus@analog.com> Link: https://lore.kernel.org/r/20220922115848.1800021-1-weiyongjun@huaweicloud.comSigned-off-by:
-
Marcus Folkesson authored
Add support for setting the Programmable Gain Amplifiers by adjust the scale value. Signed-off-by:
Marcus Folkesson <marcus.folkesson@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220922194639.1118971-1-marcus.folkesson@gmail.comSigned-off-by:
-
Crt Mori authored
The current EINVAL value is more applicable to embedded library, where user can actually put the fixed value to the sensor. In case of the driver if the value of the channel is invalid it is better in inform userspace that Channel was out of range as that implies more to internal driver error than invalid input. It also makes for easier debugging of where the error comes from during the development. Signed-off-by:
Crt Mori <cmo@melexis.com> Link: https://lore.kernel.org/r/565d4df2592d751dc0f40908f2569b7c9af8e56e.1663834141.git.cmo@melexis.comSigned-off-by:
-
Crt Mori authored
Allow users to read sensor sampling frequency to better plan the application measurement requests. Signed-off-by:
-
Crt Mori authored
The sensor can operate in lower power modes and even make measurements when in those lower powered modes. The decision was taken that if measurement is not requested within 2 seconds the sensor will remain in SLEEP_STEP power mode, where measurements are triggered on request with setting the start of measurement bit (SOB). In this mode the measurements are taking a bit longer because we need to start it and complete it. Currently, in continuous mode we read ready data and this mode is activated if sensor measurement is requested within 2 seconds. The suspend timeout is increased to 6 seconds (instead of 3 before), because that enables more measurements in lower power mode (SLEEP_STEP), with the lowest refresh rate (2 seconds). Signed-off-by:
-
Yuan Can authored
In the probe path, dev_err() can be replace with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. Signed-off-by:
Yuan Can <yuancan@huawei.com> Link: https://lore.kernel.org/r/20220921023915.47300-1-yuancan@huawei.comSigned-off-by:
-
Nuno Sá authored
Drop 'mlock' usage by making use of iio_device_claim_direct_mode(). This change actually makes sure we cannot do a single conversion while buffering is enable. Note there was a potential race in the previous code since we were only acquiring the lock after checking if the bus is enabled. Fixes: af300848 ("iio:adc: Add common code for ADI Sigma Delta devices") Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Cc: <Stable@vger.kernel.org> #No rush as race is very old. Link: https://lore.kernel.org/r/20220920112821.975359-2-nuno.sa@analog.comSigned-off-by:
-
- 30 Oct, 2022 2 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdevLinus Torvalds authored
Pull fbdev fixes from Helge Deller: "A use-after-free bugfix in the smscufx driver and various minor error path fixes, smaller build fixes, sysfs fixes and typos in comments in the stifb, sisfb, da8xxfb, xilinxfb, sm501fb, gbefb and cyber2000fb drivers" * tag 'fbdev-for-6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev: fbdev: cyber2000fb: fix missing pci_disable_device() fbdev: sisfb: use explicitly signed char fbdev: smscufx: Fix several use-after-free bugs fbdev: xilinxfb: Make xilinxfb_release() return void fbdev: sisfb: fix repeated word in comment fbdev: gbefb: Convert sysfs snprintf to sysfs_emit fbdev: sm501fb: Convert sysfs snprintf to sysfs_emit fbdev: stifb: Fall back to cfb_fillrect() on 32-bit HCRX cards fbdev: da8xx-fb: Fix error handling in .remove() fbdev: MIPS supports iomem addresses
-
