summaryrefslogtreecommitdiff
path: root/drivers/staging/iio/frequency
AgeCommit message (Collapse)Author
2026-03-21staging: iio: ad9834: use sysfs_emit() and simplify show functionsGabriel Rondon
Replace sprintf() with sysfs_emit() in sysfs attribute show functions. sysfs_emit() is the preferred API for sysfs callbacks as it is aware of the PAGE_SIZE buffer limit. Also simplify the wavetype_available show functions by removing the intermediate string variable and returning directly from each branch. Signed-off-by: Gabriel Rondon <grondon@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21staging: iio: ad9832: clean up whitespaceTomas Borquez
Remove unnecessary blank lines between comment sections to improve readability. Signed-off-by: Tomas Borquez <tomasborquez13@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21staging: iio: ad9832: remove platform_data supportTomas Borquez
Remove legacy platform_data support as there are no in tree users and this approach belongs to a long gone era. The policy decision on what to output is a userspace problem, not something that should be provided from firmware. The driver now initializes the device to a safe state (SLEEP|RESET|CLR) outputting nothing. Userspace can configure the desired frequencies and phases via the existing sysfs attributes once the device is ready to be used. Original discussion started here [1]. Link: https://lore.kernel.org/linux-iio/20250628161040.3d21e2c4@jic23-huawei/ #[1] Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Tomas Borquez <tomasborquez13@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-19staging: iio: ad9834: remove empty ad9834.h fileTaimoor Zaeem
Remove drivers/staging/iio/frequency/ad9834.h header file because it contains nothing except the include guards. Signed-off-by: Taimoor Zaeem <taimoorzaeem@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-05-21iio: frequency: ad9832: Remove unused parameter from data documentationGabriel Shahrouzi
This is a leftover from the patch: commit 566564e80b0e ("staging: iio: ad9832: use clock framework for clock reference"). The AD9832 driver uses the Common Clock Framework (CCF) to obtain the master clock (MCLK) frequency rather than relying on a frequency value passed from platform data. Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com> Link: https://patch.msgid.link/20250417173333.607844-1-gshahrouzi@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-05-21iio: frequency: ad9832: Use FIELD_PREP macro to set bit fieldsSiddharth Menon
Use bitfield and bitmask macros to clearly specify AD9832 SPI command fields to make register write code more readable. Suggested-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Signed-off-by: Siddharth Menon <simeddon@gmail.com> Link: https://patch.msgid.link/20250416140259.13431-1-simeddon@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: normalize array sentinel styleDavid Lechner
Use `\t(\{ ?\},|\{\}|\{\s*/\*.*\*/\s*\},?)$` regex to find and replace the array sentinel in all IIO drivers to the same style. For some time, we've been trying to consistently use `{ }` (no trailing comma, no comment, one space between braces) for array sentinels in the IIO subsystem. Still nearly 50% of existing code uses a different style. To save reviewers from having to request this trivial change as frequently, let's normalize the style in all existing IIO drivers. At least when code is copy/pasted to new drivers, the style will be consistent. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250411-iio-sentinel-normalization-v1-1-d293de3e3d93@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: frequency: ad9832: devicetree probing supportSiddharth Menon
Introduce struct for device match of_device_id to avoid relying on fallback mechanisms, which could lead to false matches against other AD9832 variants in the future. Suggested-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Signed-off-by: Siddharth Menon <simeddon@gmail.com> Link: https://patch.msgid.link/20250322163211.253009-1-simeddon@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-11staging: iio: ad9834: Use devm_regulator_get_enable()Saalim Quadri
The regulators are only enabled at probe(), hence replace the boilerplate code by making use of devm_regulator_get_enable() helper. Signed-off-by: Saalim Quadri <danascape@gmail.com> Link: https://patch.msgid.link/20250306000459.1554007-1-danascape@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-11staging: iio: ad9832: Use devm_regulator_get_enable()Saalim Quadri
The regulators are only enabled at probe(), hence replace the boilerplate code by making use of devm_regulator_get_enable() helper. Signed-off-by: Saalim Quadri <danascape@gmail.com> Link: https://patch.msgid.link/20250306000040.1550656-1-danascape@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-12-07staging: iio: ad9832: Correct phase range checkZicheng Qu
User Perspective: When a user sets the phase value, the ad9832_write_phase() is called. The phase register has a 12-bit resolution, so the valid range is 0 to 4095. If the phase offset value of 4096 is input, it effectively exactly equals 0 in the lower 12 bits, meaning no offset. Reasons for the Change: 1) Original Condition (phase > BIT(AD9832_PHASE_BITS)): This condition allows a phase value equal to 2^12, which is 4096. However, this value exceeds the valid 12-bit range, as the maximum valid phase value should be 4095. 2) Modified Condition (phase >= BIT(AD9832_PHASE_BITS)): Ensures that the phase value is within the valid range, preventing invalid datafrom being written. Impact on Subsequent Logic: st->data = cpu_to_be16(addr | phase): If the phase value is 2^12, i.e., 4096 (0001 0000 0000 0000), and addr is AD9832_REG_PHASE0 (1100 0000 0000 0000), then addr | phase results in 1101 0000 0000 0000, occupying DB12. According to the section of WRITING TO A PHASE REGISTER in the datasheet, the MSB 12 PHASE0 bits should be DB11. The original condition leads to incorrect DB12 usage, which contradicts the datasheet and could pose potential issues for future updates if DB12 is used in such related cases. Fixes: ea707584bac1 ("Staging: IIO: DDS: AD9832 / AD9835 driver") Cc: stable@vger.kernel.org Signed-off-by: Zicheng Qu <quzicheng@huawei.com> Link: https://patch.msgid.link/20241107011015.2472600-3-quzicheng@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-12-07staging: iio: ad9834: Correct phase range checkZicheng Qu
User Perspective: When a user sets the phase value, the ad9834_write_phase() is called. The phase register has a 12-bit resolution, so the valid range is 0 to 4095. If the phase offset value of 4096 is input, it effectively exactly equals 0 in the lower 12 bits, meaning no offset. Reasons for the Change: 1) Original Condition (phase > BIT(AD9834_PHASE_BITS)): This condition allows a phase value equal to 2^12, which is 4096. However, this value exceeds the valid 12-bit range, as the maximum valid phase value should be 4095. 2) Modified Condition (phase >= BIT(AD9834_PHASE_BITS)): Ensures that the phase value is within the valid range, preventing invalid datafrom being written. Impact on Subsequent Logic: st->data = cpu_to_be16(addr | phase): If the phase value is 2^12, i.e., 4096 (0001 0000 0000 0000), and addr is AD9834_REG_PHASE0 (1100 0000 0000 0000), then addr | phase results in 1101 0000 0000 0000, occupying DB12. According to the section of WRITING TO A PHASE REGISTER in the datasheet, the MSB 12 PHASE0 bits should be DB11. The original condition leads to incorrect DB12 usage, which contradicts the datasheet and could pose potential issues for future updates if DB12 is used in such related cases. Fixes: 12b9d5bf76bf ("Staging: IIO: DDS: AD9833 / AD9834 driver") Cc: stable@vger.kernel.org Signed-off-by: Zicheng Qu <quzicheng@huawei.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20241107011015.2472600-2-quzicheng@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-24staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()Zicheng Qu
In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value. Link: https://lore.kernel.org/all/2024100904-CVE-2024-47663-9bdc@gregkh/ Fixes: ea707584bac1 ("Staging: IIO: DDS: AD9832 / AD9835 driver") Cc: stable@vger.kernel.org Signed-off-by: Zicheng Qu <quzicheng@huawei.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20241022134354.574614-1-quzicheng@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-07-29staging: iio: frequency: ad9834: Validate frequency parameter valueAleksandr Mishin
In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value. Modify parameters checking. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 12b9d5bf76bf ("Staging: IIO: DDS: AD9833 / AD9834 driver") Suggested-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20240703154506.25584-1-amishin@t-argos.ru Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-11staging: iio: Use devm_clk_get_enabled() helper functionJinjie Ruan
The devm_clk_get_enabled() helper: - calls devm_clk_get() - calls clk_prepare_enable() and registers what is needed in order to call clk_disable_unprepare() when needed, as a managed resource. This simplifies the code and avoids the need of a dedicated function used with devm_add_action_or_reset(). Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20230825095612.2972892-1-ruanjinjie@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-10-20staging: iio: frequency: ad9834: merge unnecessary split linesDeepak R Varma
Improve code readability by merging unnecessary split lines that are well within the code-style guidelines post merge. Signed-off-by: Deepak R Varma <drv@mailo.com> Acked-by: Julia Lawall <julia.lawall@inria.fr> Link: https://lore.kernel.org/r/Y0z2/qFe3kW96MTs@debian-BULLSEYE-live-builder-AMD64 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-20staging: iio: frequency: ad9832: Fix alignment for DMA safetyJonathan Cameron
____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Whilst here, move the marking to cover the whole union. That has no functional affect, but makes it slightly easier to see what is going on. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220813160600.1157169-1-jic23@kernel.org
2022-08-15staging: iio: frequency: ad9834: Fix alignment for DMA safetyJonathan Cameron
____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220807151218.656881-3-jic23@kernel.org
2021-10-17staging: iio: ad9832: convert probe to device-managedAlexandru Ardelean
This change does a conversion of the driver to use device-managed init functions. The 2 regulators and the clock inits are converted to use devm_add_action_or_reset() callbacks for de-initializing them when the driver unloads. And finally the devm_iio_device_register() function can be use to register the device. The remove hook can finally be removed and the spi_set_drvdata() call can also be removed as the private data is no longer used. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210913115209.300665-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-05-10staging: iio: frequency: ad9834: Provide missing description for 'devid'Lee Jones
Also demote kernel-doc abuses Fixes the following W=1 kernel build warning(s): drivers/staging/iio/frequency/ad9834.c:87: warning: Function parameter or member 'devid' not described in 'ad9834_state' drivers/staging/iio/frequency/ad9834.c:93: warning: cannot understand function prototype: 'enum ad9834_supported_device_ids ' drivers/staging/iio/frequency/ad9834.c:320: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-iio@vger.kernel.org Cc: linux-staging@lists.linux.dev Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210414181129.1628598-22-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-25staging: iio: ad9832: kernel-doc fixesMugilraj Dhavachelvan
Fixes a W=1 warning. -Added ``:`` to lock parameter in 'ad9832_state' description. -It's a reference comment so removed /** Signed-off-by: Mugilraj Dhavachelvan <dmugil2000@gmail.com> Link: https://lore.kernel.org/r/20210315133711.26860-1-dmugil2000@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-25staging: iio: ad9834: convert to device-managed functions in probeAlexandru Ardelean
This change converts the driver to use device-managed functions in the probe function. For the clock and regulator disable, some devm_add_action_or_reset() calls are required, and then devm_iio_device_register() function can be used register the IIO device. The final aim here would be for IIO to export only the device-managed functions of it's API. That's a long way to go and this a small step in that direction. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210310095131.47476-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-08-22staging: iio: ad9834: Remove excess blank lineCalvin Glisson
Remove excess blank line after variable declarations. Improves code consistency and readability. Change suggested by checkpatch.pl: CHECK: Please don't use multiple blank lines Signed-off-by: Calvin Glisson <taragaram@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-14iio: remove explicit IIO device parent assignmentAlexandru Ardelean
This patch applies the semantic patch: @@ expression I, P, SP; @@ I = devm_iio_device_alloc(P, SP); ... - I->dev.parent = P; It updates 302 files and does 307 deletions. This semantic patch also removes some comments like '/* Establish that the iio_dev is a child of the i2c device */' But this is is only done in case where the block is left empty. The patch does not seem to cover all cases. It looks like in some cases a different variable is used in some cases to assign the parent, but it points to the same reference. In other cases, the block covered by ... may be just too big to be covered by the semantic patch. However, this looks pretty good as well, as it does cover a big bulk of the drivers that should remove the parent assignment. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-10-18staging: iio: ad9834: add a check for devm_clk_getChuhong Yuan
ad9834_probe misses a check for devm_clk_get and may cause problems. Add a check like what ad9832 does to fix it. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-05-26staging: iio: ad9834: add of_device_id tableJoão Victor Marques de Oliveira
Add a of_device_id struct array of_match_table variable and subsequent call to MODULE_DEVICE_TABLE macro to enable explicit device tree support. Co-developed-by: Thiago L. A. Miller <tmiller@mochsl.org.br> Signed-off-by: Thiago L. A. Miller <tmiller@mochsl.org.br> Co-developed-by: Osvaldo M. Yasuda <omyasuda@yahoo.com.br> Signed-off-by: Osvaldo M. Yasuda <omyasuda@yahoo.com.br> Signed-off-by: João Victor Marques de Oliveira <joao.marques.oliveira@usp.br> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-14staging: iio: ad9832: use clock framework for clock referenceMarcelo Schmitt
Previously external clock were set through platform_data struct. Now device uses clk struct defined in include/linux/clk.h to handle external clock source. It also removes mclk from platform_data struct. Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-14staging: iio: ad9832: organize includesMarcelo Schmitt
Organize includes to list them in lexicographic order. Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-14staging: iio: frequency: ad9834: Remove unnecessary parenthesesMelissa Wen
Remove unneeded parentheses around the arguments of ||. This reduces clutter and code behave in the same way. Change suggested by checkpatch.pl. CHECK: Unnecessary parentheses around 'st->devid == ID_AD9833' CHECK: Unnecessary parentheses around 'st->devid == ID_AD9837' Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-03staging: iio: add proper SPDX identifiers to remaining driver filesGreg Kroah-Hartman
There are a number of IIO staging drivers that do not have a proper SPDX identifier on it. So fix that up and at the same time, remove the "free form" license text, as that's pretty much impossible for any tool to parse. Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-03staging: add missing SPDX lines to Makefile filesGreg Kroah-Hartman
There are a few remaining drivers/staging/*/Makefile files that do not have SPDX identifiers in them. Add the correct GPL-2.0 identifier to them to make scanning tools happy. Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-03staging: add missing SPDX lines to Kconfig filesGreg Kroah-Hartman
There are a few remaining drivers/staging/*/Kconfig files that do not have SPDX identifiers in them. Add the correct GPL-2.0 identifier to them to make scanning tools happy. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-02staging: iio: frequency: ad9833: Load clock using clock frameworkBeniamin Bia
The clock frequency is loaded from device-tree using clock framework instead of statically value. The change allow configuration of the device via device-trees and better initialization sequence. This is part of broader effort to add device-tree support to this driver and take it out from staging. Signed-off-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-02-02staging: iio: frequency: ad9833: Get frequency value staticallyBeniamin Bia
The values from platform data were replaced by statically values. This was just a intermediate step of taking this driver out of staging and load data from device tree. Signed-off-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-08-19drivers: iio: Update MODULE AUTHOR email addressMichael Hennerich
no functional changes Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-08-22staging:iio:frequency: drop assign iio_info.driver_moduleJonathan Cameron
The equivalent of this is now done via macro magic when the relevant register call is made. The actual structure elements will shortly go away. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
2017-05-01iio: ad9834 convert symbolic permissions to octalQuentin Swain
Remove checkpatch warnings by converting symbolic S_IRUGO and S_IWUSR permissions to octal Signed-off-by: Quentin Swain <dudebrobro179@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-04-02staging: iio: ad9832: use 4-digit octal permissionsGuru Das Srinagesh
This fixes the coding style issue of using S_IWUSR in place of 4-digit octal numbers. Issue detected by checkpatch. Signed-off-by: Guru Das Srinagesh <gurooodas@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-03-15staging: iio: ad9834: Remove unnecessary goto statementsayli karnik
The patch removes unnecessary use of goto statement. Signed-off-by: sayli karnik <karniksayli1995@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-03-15staging: iio: ad9834: Use private driver lock instead of mlocksayli karnik
iio_dev->mlock should be used by the IIO core only for protecting device operating mode changes. ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. Replace mlock with a lock in the device's global data to protect hardware state changes. Signed-off-by: sayli karnik <karniksayli1995@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-03-13staging: iio: ad9832: replace mlock with driver private lockAlison Schofield
The IIO subsystem is redefining iio_dev->mlock to be used by the IIO core only for protecting device operating mode changes. ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. In this driver, mlock was being used to protect hardware state changes. Replace it with a lock in the devices global data. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-03-02staging: iio: ad9834: Moved contents of the header to the source fileNarcisa Ana Maria Vasile
Moved the contents of the header(ad9834.h) into the corresponding source file with the exception of the platform data struct which is supposed to be used from somewhere else other than the driver. Signed-off-by: Narcisa Ana Maria Vasile <narcisaanamaria12@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-03-02staging: iio: ad9832: Moved contents of the header to the source fileNarcisa Ana Maria Vasile
Moved the contents of the header(ad9832.h) into the corresponding source file with the exception of the platform data struct which is supposed to be used from somewhere else other than the driver. Signed-off-by: Narcisa Ana Maria Vasile <narcisaanamaria12@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-11-08staging: iio: ad9832: allocate data before usingArnd Bergmann
The regulator changes assigned data to an uninitialized pointer: drivers/staging/iio/frequency/ad9832.c: In function 'ad9832_probe': drivers/staging/iio/frequency/ad9832.c:214:11: error: 'st' may be used uninitialized in this function [-Werror=maybe-uninitialized] This moves the allocation of the 'st' structure before its first use, as it should have been. Fixes: 43a07e48af44 ("staging: iio: ad9832: clean-up regulator 'reg'") Fixes: a98461d79ba5 ("staging: iio: ad9832: add DVDD regulator") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-11-05staging: iio: ad9832: clean-up regulator 'reg'Eva Rachel Retuya
Rename regulator 'reg' to 'avdd' so as to be clear what regulator it stands for specifically. Additionally, get rid of local variable 'reg' and use direct assignment instead. Update also the goto label pertaining to the avdd regulator during disable. Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-11-05staging: iio: ad9832: add DVDD regulatorEva Rachel Retuya
The AD9832/AD9835 is supplied with two power sources: AVDD as analog supply voltage and DVDD as digital supply voltage. Attempt to fetch and enable the regulator 'dvdd'. Bail out if any error occurs. Suggested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-11-05staging: iio: rework regulator handlingEva Rachel Retuya
Currently, the affected drivers ignore all errors from regulator_get(). The way it is now, it also breaks probe deferral (EPROBE_DEFER). The correct behavior is to propagate the error to the upper layers so they can handle it accordingly. Rework the regulator handling so that it matches the standard behavior. If the specific design uses a static always-on regulator and does not explicitly specify it, regulator_get() will return the dummy regulator. The following semantic patch was used to apply the change: @r1@ expression reg, dev, en, volt; @@ reg = \(devm_regulator_get\|regulator_get\)(dev, ...); if ( - ! IS_ERR(reg)) + return PTR_ERR(reg); ( - { en = regulator_enable(reg); - if (en) return en; } + + en = regulator_enable(reg); + if (en) { + dev_err(dev, "Failed to enable specified supply\n"); + return en; } | + - { en = regulator_enable(reg); - if (en) return en; - volt = regulator_get_voltage(reg); } + en = regulator_enable(reg); + if (en) { + dev_err(dev, "Failed to enable specified supply\n"); + return en; + } + volt = regulator_get_voltage(reg); ) @r2@ expression arg; @@ - if (!IS_ERR(arg)) regulator_disable(arg); + regulator_disable(arg); Hand-edit the debugging prints with the supply name to become more specific. Suggested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-11-05staging: iio: set proper supply name to devm_regulator_get()Eva Rachel Retuya
The name passed to devm_regulator_get() should match the name of the supply as specified in the device datasheet. This makes it clear what power supply is being referred to in case of presence of other regulators. Currently, the supply name specified on the affected devices is 'vcc'. Use lowercase version of the datasheet name to specify the supply voltage. Suggested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-03-28Staging: iio: ad9832: Replace 'unsigned' with 'unsigned int'Svetlana Orlik
Replace 'unsigned' with 'unsigned int' to avoid checkpatch.pl warning. Signed-off-by: Svetlana Orlik <sveta.orlik.code@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-02Staging: iio: frequency: use dev_get_platdata()Nizam Haider
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Nizam Haider <nijamh@cdac.in> Signed-off-by: Jonathan Cameron <jic23@kernel.org>