summaryrefslogtreecommitdiffstats
path: root/drivers/iio/adc
AgeCommit message (Collapse)AuthorFilesLines
2020-07-20iio: adc: palmas_gpadc: Demote non-conforming kerneldoc headerLee Jones1-2/+1
Very few of the struct attributes have been documented here. Fixes the following W=1 kernel build warning(s): drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'dev' not described in 'palmas_gpadc' drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'palmas' not described in 'palmas_gpadc' drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'irq' not described in 'palmas_gpadc' drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'irq_auto_0' not described in 'palmas_gpadc' drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'irq_auto_1' not described in 'palmas_gpadc' drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'adc_info' not described in 'palmas_gpadc' drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'conv_completion' not described in 'palmas_gpadc' drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'wakeup1_data' not described in 'palmas_gpadc' drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'wakeup2_data' not described in 'palmas_gpadc' drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'wakeup1_enable' not described in 'palmas_gpadc' drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'wakeup2_enable' not described in 'palmas_gpadc' Cc: Pradeep Goudagunta <pgoudagunta@nvidia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: max9611: Demote obvious misuse of kerneldoc to standard comment blocksLee Jones1-2/+2
No attempt has been made to document any of the demoted structs here. Fixes the following W=1 kernel build warning(s): drivers/iio/adc/max9611.c:117: warning: cannot understand function prototype: 'const unsigned int max9611_mux_conf[][2] = ' drivers/iio/adc/max9611.c:145: warning: cannot understand function prototype: 'const unsigned int max9611_gain_conf[][2] = ' Cc: Jacopo Mondi <jacopo+renesas@jmondi.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: max1363: Fix kerneldoc attribute formatting for 'lock'Lee Jones1-1/+1
Kerneldoc expects attributes/parameters to be in '@*.: ' format. Fixes the following W=1 kernel build warning(s): drivers/iio/adc/max1363.c:190: warning: Function parameter or member 'lock' not described in 'max1363_state' Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Rohit Sarkar <rohitsarkar5398@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: cpcap-adc: Demote seemingly unintentional kerneldoc headerLee Jones1-3/+3
None of the headers demoted here provide any descriptions. Fixes the following W=1 kernel build warning(s): drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member 'ato_in' not described in 'cpcap_adc_ato' drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member 'atox_in' not described in 'cpcap_adc_ato' drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member 'adc_ps_factor_in' not described in 'cpcap_adc_ato' drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member 'atox_ps_factor_in' not described in 'cpcap_adc_ato' drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member 'ato_out' not described in 'cpcap_adc_ato' drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member 'atox_out' not described in 'cpcap_adc_ato' drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member 'adc_ps_factor_out' not described in 'cpcap_adc_ato' drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member 'atox_ps_factor_out' not described in 'cpcap_adc_ato' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_AD0' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BATTP' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_VBUS' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_AD3' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BPLUS_AD4' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_CHG_ISENSE' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BATTI' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_USB_ID' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_AD8' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_AD9' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_LICELL' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_HV_BATTP' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_TSX1_AD12' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_TSX2_AD13' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_TSY1_AD14' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_TSY2_AD15' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BATTP_PI16' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BATTI_PI17' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_CHANNEL_NUM' not described in enum 'cpcap_adc_channel' drivers/iio/adc/cpcap-adc.c:165: warning: Enum value 'CPCAP_ADC_TIMING_IMM' not described in enum 'cpcap_adc_timing' drivers/iio/adc/cpcap-adc.c:165: warning: Enum value 'CPCAP_ADC_TIMING_IN' not described in enum 'cpcap_adc_timing' drivers/iio/adc/cpcap-adc.c:165: warning: Enum value 'CPCAP_ADC_TIMING_OUT' not described in enum 'cpcap_adc_timing' Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: at91-sama5d2_adc: Struct kerneldoc titles need to start with 'struct 'Lee Jones1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/iio/adc/at91-sama5d2_adc.c:360: warning: cannot understand function prototype: 'struct at91_adc_dma ' drivers/iio/adc/at91-sama5d2_adc.c:379: warning: cannot understand function prototype: 'struct at91_adc_touch ' Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: at91_adc: Fix 'bad line' warningLee Jones1-1/+1
All lines should start with ' *'. Fixes the following W=1 kernel build warning(s): drivers/iio/adc/at91_adc.c:160: warning: bad line: (Interruptions registers mostly) Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: ad799x: Demote seemingly unintentional kerneldoc headerLee Jones1-1/+1
This is the only use of function related kerneldoc in the sourcefile and no descriptions are provided. Fixes the following W=1 kernel build warning(s): drivers/iio/adc/ad799x.c:192: warning: Function parameter or member 'irq' not described in 'ad799x_trigger_handler' drivers/iio/adc/ad799x.c:192: warning: Function parameter or member 'p' not described in 'ad799x_trigger_handler' Cc: Michael Hennerich <Michael.Hennerich@analog.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: twl6030-gpadc: Fix some misdocumentation and formatting issuesLee Jones1-2/+2
Kerneldoc expects attributes/parameters to be in '@*.: ' format. Fixes the following W=1 kernel build warning(s): drivers/iio/adc/twl6030-gpadc.c:110: warning: Function parameter or member 'ideal' not described in 'twl6030_gpadc_platform_data' drivers/iio/adc/twl6030-gpadc.c:110: warning: Function parameter or member 'channel_to_reg' not described in 'twl6030_gpadc_platform_data' Cc: Stephen Boyd <swboyd@chromium.org> Cc: Nishant Kamat <nskamat@ti.com> Cc: Balaji T K <balajitk@ti.com> Cc: Graeme Gregory <gg@slimlogic.co.uk> Cc: Girish S Ghongdemath <girishsg@ti.com> Cc: Ambresh K <ambresh@ti.com> Cc: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com> Cc: Mikko Ylinen <mikko.k.ylinen@nokia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: twl4030-madc: Fix misnamed struct attributeLee Jones1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/iio/adc/twl4030-madc.c:170: warning: Function parameter or member 'usb3v1' not described in 'twl4030_madc_data' Also drop a duplicate description of the lock. Cc: J Keerthy <j-keerthy@ti.com> Cc: Mikko Ylinen <mikko.k.ylinen@nokia.com> Cc: Amit Kucheria <amit.kucheria@canonical.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: twl4030-madc: Remove set but unused variables 'len'Lee Jones1-5/+5
Fixes the following W=1 kernel build warning(s): drivers/iio/adc/twl4030-madc.c: In function ‘twl4030_madc_threaded_irq_handler’: drivers/iio/adc/twl4030-madc.c:475:9: warning: variable ‘len’ set but not used [-Wunused-but-set-variable] 475 | int i, len, ret; | ^~~ Cc: Sebastian Reichel <sre@kernel.org> Cc: J Keerthy <j-keerthy@ti.com> Cc: Mikko Ylinen <mikko.k.ylinen@nokia.com> Cc: Amit Kucheria <amit.kucheria@canonical.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: ti_am335x_adc: Remove a couple of unused 'read' variablesLee Jones1-4/+4
Fixes the following W=1 kernel build warning(s): drivers/iio/adc/ti_am335x_adc.c: In function ‘tiadc_buffer_preenable’: drivers/iio/adc/ti_am335x_adc.c:297:21: warning: variable ‘read’ set but not used [-Wunused-but-set-variable] 297 | int i, fifo1count, read; | ^~~~ drivers/iio/adc/ti_am335x_adc.c: In function ‘tiadc_buffer_predisable’: drivers/iio/adc/ti_am335x_adc.c:346:21: warning: variable ‘read’ set but not used [-Wunused-but-set-variable] 346 | int fifo1count, i, read; | ^~~~ Cc: Rachna Patil <rachna@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: ad7887: Demote seemingly unintentional kerneldoc headerLee Jones1-1/+1
This is the only use of function related kerneldoc in the sourcefile and no descriptions are provided. Fixes the following W=1 kernel build warning(s): drivers/iio/adc/ad7887.c:119: warning: Function parameter or member 'irq' not described in 'ad7887_trigger_handler' drivers/iio/adc/ad7887.c:119: warning: Function parameter or member 'p' not described in 'ad7887_trigger_handler' Cc: Michael Hennerich <Michael.Hennerich@analog.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: ad7923: Demote obvious misuse of kerneldoc to standard comment blocksLee Jones1-4/+4
No attempt has been made to document either of the demoted functions here Fixes the following W=1 kernel build warning(s): drivers/iio/adc/ad7923.c:159: warning: Function parameter or member 'indio_dev' not described in 'ad7923_update_scan_mode' drivers/iio/adc/ad7923.c:159: warning: Function parameter or member 'active_scan_mask' not described in 'ad7923_update_scan_mode' drivers/iio/adc/ad7923.c:202: warning: Function parameter or member 'irq' not described in 'ad7923_trigger_handler' drivers/iio/adc/ad7923.c:202: warning: Function parameter or member 'p' not described in 'ad7923_trigger_handler' Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Patrick Vasseur <patrick.vasseur@c-s.fr> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: ad7298: Demote obvious misuse of kerneldoc to standard comment blocksLee Jones1-4/+4
No attempt has been made to document either of the demoted functions here. Fixes the following W=1 kernel build warning(s): drivers/iio/adc/ad7298.c:106: warning: Function parameter or member 'indio_dev' not described in 'ad7298_update_scan_mode' drivers/iio/adc/ad7298.c:106: warning: Function parameter or member 'active_scan_mask' not described in 'ad7298_update_scan_mode' drivers/iio/adc/ad7298.c:154: warning: Function parameter or member 'irq' not described in 'ad7298_trigger_handler' drivers/iio/adc/ad7298.c:154: warning: Function parameter or member 'p' not described in 'ad7298_trigger_handler' Cc: Michael Hennerich <Michael.Hennerich@analog.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: adc: ad_sigma_delta: Remove unused variable 'ret'Lee Jones1-5/+2
Fixes the following W=1 kernel build warning(s): drivers/iio/adc/ad_sigma_delta.c: In function ‘ad_sd_trigger_handler’: drivers/iio/adc/ad_sigma_delta.c:405:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] 405 | int ret; | ^~~ Cc: Michael Hennerich <Michael.Hennerich@analog.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20Merge 5.8-rc6 into staging-nextGreg Kroah-Hartman2-3/+3
We need the staging fixes in here, and it resolves a merge issue with an iio driver. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-13Replace HTTP links with HTTPS ones: drivers/iioAlexander A. Klimov14-23/+23
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-07iio: adc: ti_am335x_adc: alloc kfifo & IRQ via devm_ functionsAlexandru Ardelean1-15/+5
This change attaches the life-cycle of the kfifo buffer & IRQ to the parent-device. This in turn cleans up the exit & error paths, since we don't need to explicitly cleanup these resources. The main intent here is to remove the explicit cleanup of the 'indio_dev->buffer' via 'iio_kfifo_free(indio_dev->buffer);'. As we want to add support for multiple buffers per IIO device, having it exposed like this makes it tricky to consider a safe backwards compatible approach for it. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-07iio: adc: ti_am335x_adc: alloc channels via devm_kcalloc()Alexandru Ardelean1-10/+5
This change attaches the life-cycle of the channels array to the parent device object that is attached to the IIO device. This way we can remove from the cleanup code, the explicit tiadc_channels_remove() which simply does a kfree() on the channels array. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-07iio:adc:ingenic: drop of_match_ptr protection and include mod_devicetable.hJonathan Cameron1-3/+2
Whilst it's unlikely this device will ever be instantiated using ACPI, there is little advantage not assigning the of_device_id table in all cases and it avoids providing an example that might be coppied into new drivers. Also include mod_devicetable.h whilst here as of_device_id is defined in there so including the header is best practice. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Artur Rojek <contact@artur-rojek.eu> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:ti-tlc4541: Drop CONFIG_OF and of_match_ptr protections.Jonathan Cameron1-3/+2
These stop us using ACPI PRP0001 to instantiate the device. I am slowly clearly out use of these in IIO to avoid this being coppied into new drivers. Here I also included mod_devicetable.h as we are using of_match_id which is defined in there and hence it is best practice to include it directly. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Phil Reid <preid@electromag.com.au> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:ti-adc161s626: Drop of_match_ptr protection.Jonathan Cameron1-1/+2
Dropping this allows use of ACPI PRP0001. I'm also looking to drop all of_match_ptr use in IIO in order to avoid it getting cut and paste into new drivers in the future. Also add a direct include of mod_devicetable.h to reflect the use of struct of_device_id. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Matt Ranostay <matt.ranostay@konsulko.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:ti-adc084s021: drop of_match_ptr protectionJonathan Cameron1-1/+2
Allows ACPI PRP0001 to be used with this driver. Also adds mod_devicetable.h header as the driver is directly using struct of_device_id which is defined in that file. I'm also trying to clear out of_match_ptr use in IIO to avoid it being cut and paste into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Mårten Lindahl <martenli@axis.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:ti-adc0832: drop CONFIG_OF and of_match_ptr protectionsJonathan Cameron1-5/+2
These just prevent the driver being used with ACPI PRP0001. I am also trying to remove these from IIO in general to avoid them being coppied into new drivers. Also include the mod_devicetable.h header as we are using of_device_id which is defined in there. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:ti-adc081c: Drop of_match_ptr and change to mod_devicetable.hJonathan Cameron1-4/+2
Whilst this driver already supports explicit ACPI bindings we might as well also allow for PRP0001 based binding. I'm also keen to remove of_match_ptr from IIO drivers to avoid this (now) anti-pattern getting coppied into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:sd_adc_modulator: Drop of_match_ptr and tweak includesJonathan Cameron1-2/+3
Dropping of_match_ptr allows this driver to be used with ACPI. The header includes are adjusted to include platform_device.h and mod_devicetable.h instead of OF specific header as nothing from that header itself is actually used. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Arnaud Pouliquen <arnaud.pouliquen@st.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:mcp3422: remove CONFIG_OF and of_match_ptr protectionsJonathan Cameron1-4/+2
They stop the driver being used with ACPI PRP0001 and are something I want to avoid being cut and paste into new drivers. Also switch the include from of.h to mod_devicetable.h as we struct of_device_id is defined in there and we don't use anything actually in of.h. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Angelo Compagnucci <angelo.compagnucci@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:mcp320x: Drop CONFIG_OF and of_match_ptr protectionsJonathan Cameron1-3/+2
These just prevent the driver being used with ACPI PRP0001. They also get cut and paste into new drivers and we want to discourage this from happening by cleaning it out in general. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Oskar Andero <oskar.andero@gmail.com> Cc: Søren Andersen <san@rosetechnology.dk> Cc: Lukas Wunner <lukas@wunner.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:max1118: Drop CONFIG_OF / of_match_ptr protectionsJonathan Cameron1-5/+2
These just stop the driver being used with ACPI PRP0001 and we are trying to clear them out of IIO to avoid them getting copied into new drivers. Also add the mod_devicetable.h include as we are using struct of_device_id which is defined in there. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:max11100: Drop of_match_ptr protection / add mod_devicetable.h includeJonathan Cameron1-1/+2
Allows use of driver with ACPI PRP0001 base binding. Mostly this is about trying to avoid cut and paste of this into new drivers (it is a frequent review comment) rather than any thought that this driver might get used on an ACPI platform. The mod_devicetable.h include is to encourage best practice of including any header directly used within the code (here for of_match_id) Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:ltc2497 drop of_match_ptr protectionJonathan Cameron1-2/+2
This prevents the driver being used with ACPI PRP0001 based bindings. Also switch include to mod_devicetable.h which devices the used id structure. Note this is most about removing something I don't want want cut and paste into new driver rather than any thought that this particular driver will be used in an ACPI system (though it might!) Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:cpcap-adc: Drop of_match_ptr protection and use device_get_match_dataJonathan Cameron1-16/+6
Part of a slow effort to avoid OF specific code in IIO. Whilst the main advantages of this are not likely to be seen in this particular driver (ACPI support via PRP0001) the change proposed does make things a bit more maintainable and also ensures that this particular (now) anti-patern is less likely to be cut and paste into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:ltc2496: Drop of_match_ptr and use mod_devicetable.hJonathan Cameron1-2/+2
The macro prevents use of driver with ACPI PRP0001 and the of_match_id structure is defined in mod_devicetable.h so include that directly rather than of.h. Note this is mostly about removing something I don't want cut and paste into new drivers rather than expectation that this particular driver will be used on an ACPI platform. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:max1027: drop of_match_ptr and CONFIG_OF protectionsJonathan Cameron1-3/+2
These just prevent the driver being used with ACPI PRP0001 and provide no major benefits. Part of clearing these out in general in IIO to avoid cut and paste repetition in new drivers. Also include mod_devicetable.h as we directly make use of of_device_id which is defined in there. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Philippe Reynes <tremyfr@yahoo.fr> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:max1363: Drop of_match_ptr and use generic device_get_match_dataJonathan Cameron1-7/+4
Allows driver to use ACPI PRP0001 binding and there was no particular advantage in having the protections in this driver. Mostly this part of an effort to remove as many OF specific bits of handling from IIO and use the generic forms where possible. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:hi8435: Drop of_match_ptr protection.Jonathan Cameron1-3/+2
Allows use of ACPI with PRP0001 and is generally something we are trying to avoid having people cut and paste into new drivers without thinking about it. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:hi8435: Drop unused of_gpio.h headerJonathan Cameron1-1/+0
I guess this is a left over from some earlier cleanup. Not used currently. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio:adc:lpc32xx: Drop of_match_ptr protectionJonathan Cameron1-3/+2
Whilst is unlikely anyone will be using this part with an ACPI PRP0001 based binding any time soon, we are getting a lot of cut and pasting of this pattern so I am looking to remove it entirely from IIO. In this case CONFIG_OF protections also removed and mod_devicetable.h include added given direct use of struct of_device_id. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2020-07-07iio: at91-sama5d2_adc: remove usage of iio_priv_to_dev() helperAlexandru Ardelean1-13/+17
We may want to get rid of the iio_priv_to_dev() helper. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. The iio_priv() helper won't be affected by the rework, as the iio_dev struct will keep a reference to the private information. For this driver, not using iio_priv_to_dev(), means reworking some paths to pass the iio device and using iio_priv() to access the private information, and also keeping a reference to the iio device for some quirky paths. One [quirky] path is the at91_adc_workq_handler() which requires the IIO device & the state struct to push to buffers. Since this requires the back-ref to the IIO device, the at91_adc_touch_pos() also uses it. This simplifies the patch a bit. The information required in this function is mostly for debugging purposes. Replacing it with a reference to the IIO device would have been a slightly bigger change, which may not be worth it (for just the debugging purpose and given that we need the back-ref to the IIO device anyway). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-05iio: adc: ad7780: Fix a resource handling path in 'ad7780_probe()'Christophe JAILLET1-1/+1
If 'ad7780_init_gpios()' fails, we must not release some resources that have not been allocated yet. Return directly instead. Fixes: 5bb30e7daf00 ("staging: iio: ad7780: move regulator to after GPIO init") Fixes: 9085daa4abcc ("staging: iio: ad7780: add gain & filter gpio support") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Renato Lui Geh <renatogeh@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-04iio: adc: adi-axi-adc: Fix object reference countingNuno Sá1-2/+2
When looking for a registered client to attach with, the wrong reference counters are being grabbed. The idea is to increment the module and device counters of the client device and not the counters of the axi device being probed. Fixes: ef04070692a2 (iio: adc: adi-axi-adc: add support for AXI ADC IP core) Signed-off-by: Nuno Sá <nuno.sa@analog.com> Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-27iio: adc: Combine read functions for PMIC5 and PMIC7Jishnu Prakash1-30/+19
Add a common function used for read_raw callback for both PMIC5 and PMIC7 ADCs. Signed-off-by: Jishnu Prakash <jprakash@codeaurora.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-27iio: adc: rockchip_saradc: Add support iio buffersSimon Xue1-35/+110
Add the ability to also support access via (triggered) buffers next to the existing direct mode. Device in question is the Odroid Go Advance that connects a joystick to two of the saradc channels for X and Y axis and the new (and still pending) adc joystick driver of course wants to use triggered buffers from the iio subsystem. Signed-off-by: Simon Xue <xxm@rock-chips.com> [some simplifications and added commit description] Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-27iio: adc: rockchip_saradc: better prefix for channel constantHeiko Stuebner1-12/+12
As suggested give the current ADC_CHANNEL constant a distinct and consistent prefix. Suggested-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-27iio: adc: rockchip_saradc: move all of probe to devm-functionsHeiko Stuebner1-29/+45
Parts of the saradc probe rely on devm functions and later parts do not. This makes it more difficult to for example enable triggers via their devm-functions and would need more undo-work in remove. So to make life easier for the driver, move the rest of probe calls also to their devm-equivalents. This includes moving the clk- and regulator-disabling to a devm_action so that they gets disabled both during remove and in the error case in probe, after the action is registered. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-20iio: Move attach/detach of the poll func to the coreLars-Peter Clausen15-129/+13
All devices using a triggered buffer need to attach and detach the trigger to the device in order to properly work. Instead of doing this in each and every driver by hand move this into the core. At this point in time, all drivers should have been resolved to attach/detach the poll-function in the same order. This patch removes all explicit calls of iio_triggered_buffer_postenable() & iio_triggered_buffer_predisable() in all drivers, since the core handles now the pollfunc attach/detach. The more peculiar change is for the 'at91-sama5d2_adc' driver, since it's not immediately obvious that removing the hooks doesn't break anything. Eugen was able to test on at91-sama5d2-adc driver, sama5d2-xplained board. All seems to be fine. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Tested-by: Eugen Hristev <eugen.hristev@microchip.com> #for at91-sama5d2-adc Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-20iio: at91_adc: remove usage of iio_priv_to_dev() helperAlexandru Ardelean1-15/+15
We may want to get rid of the iio_priv_to_dev() helper. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. The iio_priv() helper won't be affected by the rework, as the iio_dev struct will keep a reference to the private information. For this driver, not using iio_priv_to_dev(), means reworking some paths to pass the iio device and using iio_priv() to access the private information. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Tested-by: Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-20iio: stm32-dfsdm-adc: remove usage of iio_priv_to_dev() helperAlexandru Ardelean1-32/+33
We may want to get rid of the iio_priv_to_dev() helper. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. The iio_priv() helper won't be affected by the rework, as the iio_dev struct will keep a reference to the private information. For this driver, not using iio_priv_to_dev(), means reworking some paths to pass the iio device and using iio_priv() to access the private information. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-14iio: Remove superfluous of_node assignmentsLars-Peter Clausen49-50/+0
If a driver does not assign an of_node to a IIO device to IIO core will automatically assign the of_node of the parent device. This automatic assignment is done in the iio_device_register() function. There is a fair amount of drivers that currently manually assign the of_node of the IIO device. All but 4 of them can make use of the automatic assignment though. The exceptions are: * mxs-lradc-adc: Which uses the of_node of the parent of the parent. * stm32-dfsdm-adc, stm32-adc and stm32-dac: Which reference the of_node assigned to the IIO device before iio_device_register() is called. All other drivers are updated to use automatic assignment. This reduces the amount of boilerplate code involved in setting up the IIO device. The patch has mostly been auto-generated with the following semantic patch // <smpl> @exists@ expression indio_dev; expression parent; @@ indio_dev = \(devm_iio_device_alloc\|iio_device_alloc\)(&parent, ...) ... -indio_dev->dev.of_node = parent.of_node; @exists@ expression indio_dev; expression parent; @@ indio_dev = \(devm_iio_device_alloc\|iio_device_alloc\)(parent, ...) ... -indio_dev->dev.of_node = parent->of_node; // </smpl> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-14iio: remove left-over parent assignmentsAlexandru Ardelean6-7/+0
These were found by doing some shell magic: ------------ for file in $(git grep -w devm_iio_device_alloc | cut -d: -f1 | sort | uniq) ; do if grep 'parent =' $file | grep -v trig | grep -vq devm_; then echo "$file -> $(grep "parent =" $file)" fi done ----------- The output is bearable [after the semantic patch is applied]. There is a mix of trigger assignments with some iio device parent assignments that are removed via this patch. JC: A few more added via inspection of all parent = statements in drivers/iio. Some of these may just have crossed with this series, others were less obvious to scripting due to some cross file / module boundary calls. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-14 20:34:44 +0000