- 28 Apr, 2022 32 commits
-
-
Cixi Geng authored
Small adjustment the scale calibration value for the sc2731, use new name sc2731_[big|small]_scale_graph_calib, and remove the origin [big|small]_scale_graph_calib struct for unused. Fixes: 8ba0dbfd (iio: adc: sc27xx: Add ADC scale calibration) Signed-off-by:
Cixi Geng <cixi.geng1@unisoc.com> Link: https://lore.kernel.org/r/20220419142458.884933-4-gengcixi@gmail.comSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Cixi Geng authored
Fix wrong configuration value of SC27XX_ADC_SCALE_MASK and SC27XX_ADC_SCALE_SHIFT by spec documetation. Fixes: 5df362a6 (iio: adc: Add Spreadtrum SC27XX PMICs ADC support) Signed-off-by:
Baolin Wang <baolin.wang7@gmail.com> Link: https://lore.kernel.org/r/20220419142458.884933-3-gengcixi@gmail.comSigned-off-by:
-
Cixi Geng authored
sprd,ump9620-adc is one variant of sc27xx series, add ump9620 description and sample in dt-bindings. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220419142458.884933-2-gengcixi@gmail.comSigned-off-by:
-
Arnaud Ferraris authored
This makes the value from which an object should be considered "near" available to userspace. This hardware-dependent value should be set in the device-tree. Signed-off-by:
Arnaud Ferraris <arnaud.ferraris@collabora.com> Link: https://lore.kernel.org/r/20220420112540.91907-3-arnaud.ferraris@collabora.comSigned-off-by:
-
Arnaud Ferraris authored
This allows exporting the value from which userspace should assert an object is "near". Signed-off-by:
-
Biju Das authored
Document renesas RZ/V2L ADC bindings. RZ/V2L ADC is identical to RZ/G2L with same number of channels. While at it remove RZ/G2LC SoC from binding documentation as it does not support ADC. Signed-off-by:
Biju Das <biju.das.jz@bp.renesas.com> Acked-by:
-
Miaoqian Lin authored
wait_for_completion_timeout() returns unsigned long not int. It returns 0 if timed out, and positive if completed. The check for <= 0 is ambiguous and should be == 0 here indicating timeout which is the only error case. Fixes: 3cef2e31 ("iio: proximity: vl53l0x: Add IRQ support") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20220412064210.10734-1-linmq006@gmail.comSigned-off-by:
-
Miaoqian Lin authored
wait_for_completion_timeout() returns unsigned long not long. it returns 0 if timed out, and positive if completed. The check for <= 0 is ambiguous and should be == 0 here indicating timeout which is the only error case Fixes: e813dde6 ("iio: stmpe-adc: Use wait_for_completion_timeout") Signed-off-by:
Philippe Schenker <philippe.schenker@toradex.com> Link: https://lore.kernel.org/r/20220412065150.14486-1-linmq006@gmail.comSigned-off-by:
-
Jonathan Cameron authored
Documentation needed to avoid build warning with W=1 builds. It doesn't really add any non obvious information but good to have it anyway. No fixes tag as not worth backporting onto the fix that added the name element to the structure. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220410153317.290896-1-jic23@kernel.org
-
Lad Prabhakar authored
ADC block is common on Renesas RZ/G2L and RZ/V2L SoC's, so instead of adding dependency for each SoC's add dependency on ARCH_RZG2L. The ARCH_RZG2L config option is already selected by ARCH_R9A07G044 and ARCH_R9A07G054. Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20220406070315.13862-1-prabhakar.mahadev-lad.rj@bp.renesas.comSigned-off-by:
-
Andy Shevchenko authored
Convert the module to be property provider agnostic and allow it to be used on non-OF platforms. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Rui Miguel Silva <rmfrfs@gmail.com> Link: https://lore.kernel.org/r/20220413131513.59258-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
Convert the module to be property provider agnostic and allow it to be used on non-OF platforms. While at it, reuse temporary device pointer in the same function. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220413163004.84789-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
Switch the IIO core to use firmware node handle instead of OF node. This will allow to get label from firmware on non-OF systems. Note, this doesn't change of_iio_*() APIs for now. Signed-off-by:
-
Andy Shevchenko authored
Convert the module to be property provider agnostic and allow it to be used on non-OF platforms. While at it, reuse temporary device pointer in the same function. Signed-off-by:
-
Andy Shevchenko authored
Instead of calling the OF specific API, use device_get_match_data(). Signed-off-by:
-
Andy Shevchenko authored
Nothing in this driver depends on OF firmware so drop the dependency to remove the false impression such a dependency exists. Signed-off-by:
-
Andy Shevchenko authored
Nothing in this driver depends on OF firmware so drop the dependency to remove the false impression such a dependency exists. Signed-off-by:
-
Andy Shevchenko authored
Convert the module to be property provider agnostic and allow it to be used on non-OF platforms. Add missing mod_devicetable.h include. Signed-off-by:
-
Andy Shevchenko authored
Nothing in this driver depends on OF firmware so drop the dependency to remove the false impression such a dependency exists. Signed-off-by:
-
Andy Shevchenko authored
Convert the module to be property provider agnostic and allow it to be used on non-OF platforms. Signed-off-by:
-
Andy Shevchenko authored
Nothing in this driver depends on OF firmware so drop the dependency to remove the false impression such a dependency exists. Signed-off-by:
-
Andy Shevchenko authored
Nothing in this driver depends on OF firmware so drop the dependency to remove the false impression such a dependency exists. Signed-off-by:
-
Andy Shevchenko authored
Nothing in this driver depends on OF firmware so drop the dependency to remove the false impression such a dependency exists. Signed-off-by:
-
Andy Shevchenko authored
Convert the module to be property provider agnostic and allow it to be used on non-OF platforms. While at it, reuse temporary device pointer in the same function. Signed-off-by:
-
Puranjay Mohan authored
Use the generic fwnode_irq_get_byname() in place of of_irq_get_byname() to get the IRQ number from the interrupt pin. Signed-off-by:
Puranjay Mohan <puranjay12@gmail.com> Link: https://lore.kernel.org/r/20211109200840.135019-3-puranjay12@gmail.comSigned-off-by:
-
Lorenzo Bianconi authored
Add device bindings for asm330lhhx IMU sensor. Use lsm6dsr as fallback device for asm330lhhx since it implements all the features currently supported by asm330lhhx. Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
-
Lorenzo Bianconi authored
Add support to STM ASM330LHHX (acc + gyro) automotive Mems sensor. The ASM330LHHX sensor can use LSM6DSR as fallback device since it implements all the ASM330LHHX features currently implemented in st_lsm6dsx. Datasheet: https://www.st.com/resource/en/datasheet/asm330lhhx.pdfSigned-off-by:
-
Nuno Sá authored
Add an entry for the ad3552r DAC driver. Signed-off-by:
Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220404085000.249423-3-nuno.sa@analog.comSigned-off-by:
-
Nuno Sá authored
As the maintainer email no longer exists, change it to myself. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220404085000.249423-2-nuno.sa@analog.comSigned-off-by:
-
Maíra Canal authored
Convert probe functions to device-managed variants, with exception of the regulator, which required a devm_add_action_or_reset() hook registration. Reviewed-by:
Marcelo Schmitt <marcelo.schmitt1@gmail.com> Reviewed-by:
Maíra Canal <maira.canal@usp.br> Link: https://lore.kernel.org/r/20220407115621.10781-1-maira.canal@usp.brSigned-off-by:
-
Lars-Peter Clausen authored
strtobool() is deprecated and just a wrapper around kstrtobool().Replace it with kstrtobool() so the deprecated function can be removed eventually. Suggested-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Reviewed-by:
-
Miquel Raynal authored
As part of a previous discussion with Jonathan Cameron [1], it appeared necessary to clarify the meaning of each mode so that new developers could understand better what they should use or not use and when. The idea of renaming these modes as been let aside because naming is a big deal and requires a lot of thinking. So for now let's focus on correctly explaining what each mode implies. [1] https://lore.kernel.org/linux-iio/20210930165510.2295e6c4@jic23-huawei/Suggested-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20220207143840.707510-14-miquel.raynal@bootlin.comSigned-off-by:
-
- 10 Apr, 2022 8 commits
-
-
Miquel Raynal authored
Among all the users of the kfifo buffers, no one uses the INDIO_BUFFER_HARDWARE mode. So let's take this as a general rule and simplify a little bit the internals - overall the documentation - by eliminating unused specific cases. Use the INDIO_BUFFER_SOFTWARE mode by default with kfifo buffers, which will basically mimic what all the "non direct" modes do. Cc: Benson Leung <bleung@chromium.org> Cc: Guenter Roeck <groeck@chromium.org> Cc: Jyoti Bhayana <jbhayana@google.com> Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Miquel Raynal authored
This entry should, under no situation, be modified by device drivers. Now that we have limited its read access to device drivers really needing it and did so through a dedicated helper, we can easily move this variable to the opaque structure in order to prevent any further modification from non-authorized code (out of the core, basically). Signed-off-by:
Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20220207143840.707510-12-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
In order to later move this variable within the opaque structure, let's create a helper for accessing it in read-only mode. This helper will be exposed to device drivers and kept accessible for the few that could need it. The write access to this variable however should be fully reserved to the core so in a second step we will hide this variable into the opaque structure. Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
-
Miquel Raynal authored
As we are going to hide the currentmode inside the opaque structure, this helper would soon need to call a non-inline function which would simply drop the benefit of having the helper defined inline in a header. One alternative is to move this helper in the core as there is no more interest in defining it inline in a header. We will pay the minor cost either way. Let's do like the iio_device_id() helper which also refers to the opaque structure and gets defined in the core. Suggested-by:
-
Miquel Raynal authored
The st_sensors_core driver hardcodes the content of the iio_device_claim_direct_mode() and iio_device_release_direct_mode() helpers. Let's get rid of this handcrafted implementation and use the proper core helpers instead. Additionally, this lowers the tab level (which is always good) and prevents the use of the ->currentmode variable which is not supposed to be used like this anyway. Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by:
-
Miquel Raynal authored
An odr_lock has been introduced to protect local accesses to the odr internal cache and ensure the cached value always reflected the actual value. Using the mlock() for this purpose is no longer needed, so let's drop these extra mutex_lock/unlock() calls. Suggested-by:
-
Miquel Raynal authored
Right now the (framework) mlock lock is (ab)used for multiple purposes: 1- protecting concurrent accesses over the odr local cache 2- avoid changing samplig frequency whilst buffer is running Let's start by handling situation #1 with a local lock. Suggested-by:
-
Miquel Raynal authored
The use of a lock there seems pointless. Besides preventing to read these information from userspace while buffers are enabled (which is not supposed to happen), it only protect read accesses over static const values, which are never supposed to be written anyway. Drop these lock calls. Suggested-by:
-
