- 10 1月, 2018 1 次提交
-
-
由 Arnaud Pouliquen 提交于
Add generic driver to support sigma delta modulators. Typically, this device is hardware connected to an IIO device in charge of the conversion. Devices are bonded through the hardware consumer API. Signed-off-by: NArnaud Pouliquen <arnaud.pouliquen@st.com> Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 02 11月, 2017 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 10月, 2017 4 次提交
-
-
由 Corentin Labbe 提交于
The usage of of_device_get_match_data reduce the code size a bit. Furthermore, it prevents an improbable dereference when of_match_device() return NULL. Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Colin Ian King 提交于
Don't populate const array ch_to_mux on the stack, instead make it static. Makes the object code smaller by over 200 bytes: Before: text data bss dec hex filename 12663 1648 128 14439 3867 drivers/iio/adc/ti-adc12138.o After text data bss dec hex filename 12353 1744 128 14225 3791 drivers/iio/adc/ti-adc12138.o (gcc version 7.2.0 x86_64) Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Fabrice Gasnier 提交于
Add check on STM32 ADC clock rate to report an explicit error. This may avoid division by 0 later in stm32-adc driver. Signed-off-by: NFabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Fabrice Gasnier 提交于
Add TIM15_TRGO trigger that is now supported on STM32H7. Signed-off-by: NFabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 15 10月, 2017 1 次提交
-
-
由 Eugen Hristev 提交于
This fix allows platforms to probe correctly even if the trigger edge property is missing. The hardware trigger will no longer be registered in the sybsystem Preserves backwards compatibility with the support that was in the driver before the hardware trigger. https://storage.kernelci.org/mainline/master/v4.14-rc2-255-g74d83ec2b734/arm/sama5_defconfig/lab-free-electrons/boot-at91-sama5d2_xplained.txtSigned-off-by: NEugen Hristev <eugen.hristev@microchip.com> Fixes: 5e1a1da0 ("iio: adc: at91-sama5d2_adc: add hw trigger and buffer support") Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 10 10月, 2017 7 次提交
-
-
由 Lukas Wunner 提交于
These ADCs are marketed as single-channel 22 bit delta-sigma ADCs, but in reality their resolution is 21 bit with an overrange or underrange of 12% beyond Vref. In other words, "full scale" means +/- 2^20. This driver does not explicitly signal back to the user when an overrange or underrange occurs, but the user can detect it by comparing the raw value to +/- 2^20 (or the scaled value to Vref). The chips feature an extended temperature range and high accuracy, low noise characteristics, but their conversion times are slow with up to 80 ms +/- 2% (on the MCP3550-50). Hence, unlike the other ADCs supported by the driver, conversion does not take place in realtime upon lowering CS. Instead, CS is asserted for 8 usec to start the conversion. After waiting for the duration of the conversion, the result can be fetched. While waiting, control of the bus is ceased so it may be used by a different device. After the result has been fetched and 10 us have passed, the chip goes into shutdown and an additional power-up delay of 144 clock periods is then required to wake the analog circuitry upon the next conversion (footnote below table 4-1, page 16 in the spec). Optionally, the chips can be used in so-called "continuous conversion mode": Conversions then take place continuously and the last result may be fetched at any time without observing a delay. The mode is enabled by permanently driving CS low, e.g. by wiring it to ground. The driver only supports "single conversion mode" for now but should be adaptable to "continuous conversion mode" with moderate effort. The chips clock out a 3 byte word, unlike the other ADCs supported by the driver which all have a lower resolution than 16 bit and thus make do with 2 bytes. Calculate the word length on probe by rounding up the resolution to full bytes. Crucially, if the clock idles low, the transfer is preceded by a useless Data Ready bit which increases its length from 24 bit to 25 bit = 4 bytes (section 5.5 in the spec). Autosense this based on the SPI slave's configuration. Cc: Mathias Duckeck <m.duckeck@kunbus.de> Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Stefan Brüns 提交于
According to the ABI documentation, the shunt resistor value should be specificied in Ohm. As this is also used/documented for the MAX9611, use the same for the INA2xx driver. This poses an ABI break for anyone actually altering the shunt value through the sysfs interface, it does not alter the default value nor a value set from the devicetree. Minor change: Fix comment, 1mA is 10^-3A. Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Geert Uytterhoeven 提交于
Use the of_device_get_match_data() helper instead of open coding. Note that the rcar-gyroadc driver is used with DT only, so there's always a valid match. Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: NSimon Horman <horms+renesas@verge.net.au> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Geert Uytterhoeven 提交于
The rcar-gyroadc driver compiles fine on other platforms, hence increase compile coverage. Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: NSimon Horman <horms+renesas@verge.net.au> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Geert Uytterhoeven 提交于
On 64-bit: drivers/iio/adc/rcar-gyroadc.c: In function 'rcar_gyroadc_parse_subdevs': drivers/iio/adc/rcar-gyroadc.c:352:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] childmode = (unsigned int)of_id->data; ^ Cast the pointer to uintptr_t instead of unsigned int to fix this. Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: NSimon Horman <horms+renesas@verge.net.au> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Quentin Schulz 提交于
Before this patch, forgetting to put a thermal-zones DT node would result in the driver failing to probe. It should be perfectly acceptable to have the driver probe even if no thermal-zones DT is found. However, it shouldn't want to fail if the thermal registering fail for any other reason (waiting for other drivers for example) so check on ENODEV only. Signed-off-by: NQuentin Schulz <quentin.schulz@free-electrons.com> Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Quentin Schulz 提交于
This driver has a get_temp function used by the thermal framework that uses pm functions. However, the driver isn't registered in pm before it is registered in thermal framework, resulting in the pm_resume not being called and thus the IP not enabled. When the IP is disabled, the raw temp value is always 0. With the devices currently supported, it isn't a problem since with their respective formula, they return a really cold SoC temperature which isn't a problem for the thermal framework. But for future SoC that have a different formula, it could return a critically hot temperature, forcing the thermal framework to shutdown the board. Signed-off-by: NQuentin Schulz <quentin.schulz@free-electrons.com> Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 08 10月, 2017 1 次提交
-
-
由 Randy Dunlap 提交于
The dln2-adc driver uses interface(s) that are controlled by the IIO_TRIGGERED_BUFFER Kconfig symbol, so the driver needs to select that symbol to prevent the build error. drivers/iio/adc/dln2-adc.o: In function `dln2_adc_probe': dln2-adc.c:(.text+0x528): undefined reference to `devm_iio_triggered_buffer_setup' Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Reported-by: Nkbuild test robot <fengguang.wu@intel.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: linux-iio@vger.kernel.org Cc: Jack Andersen <jackoalan@gmail.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 26 9月, 2017 1 次提交
-
-
由 Jonathan Cameron 提交于
The equivalent of both of these are now done via macro magic when the relevant register calls are made. The actual structure elements have gone away. Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 24 9月, 2017 12 次提交
-
-
由 Dragos Bogdan 提交于
The serial interface can be reset by writing 32 consecutive 1s to the device. 'ret' was initialized correctly but its value was overwritten when ad7793_check_platform_data() was called. Since a dedicated reset function is present now, it should be used instead. Fixes: 2edb769d ("iio:ad7793: Add support for the ad7798 and ad7799") Signed-off-by: NDragos Bogdan <dragos.bogdan@analog.com> Acked-by: NLars-Peter Clausen <lars@metafoo.de> Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Dragos Bogdan 提交于
Since most of the SD ADCs have the option of reseting the serial interface by sending a number of SCLKs with CS = 0 and DIN = 1, a dedicated function that can do this is usefull. Needed for the patch: iio: ad7793: Fix the serial interface reset Signed-off-by: NDragos Bogdan <dragos.bogdan@analog.com> Acked-by: NLars-Peter Clausen <lars@metafoo.de> Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Lukas Wunner 提交于
Commit f686a36b ("iio: adc: mcp320x: Add support for mcp3301") returns a signed voltage from mcp320x_adc_conversion() but neglects that the caller interprets a negative return value as failure. Only mcp3301 (and the upcoming mcp3550/1/3) is affected as the other chips are incapable of measuring negative voltages. Fix and while at it, add mcp3301 to the list of supported chips at the top of the file. Fixes: f686a36b ("iio: adc: mcp320x: Add support for mcp3301") Cc: Andrea Galbusera <gizero@gmail.com> Signed-off-by: NLukas Wunner <lukas@wunner.de> Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Lukas Wunner 提交于
The driver calls spi_get_drvdata() in its ->remove hook even though it has never called spi_set_drvdata(). Stack trace for posterity: Unable to handle kernel NULL pointer dereference at virtual address 00000220 Internal error: Oops: 5 [#1] SMP ARM [<8072f564>] (mutex_lock) from [<7f1400d0>] (iio_device_unregister+0x24/0x7c [industrialio]) [<7f1400d0>] (iio_device_unregister [industrialio]) from [<7f15e020>] (mcp320x_remove+0x20/0x30 [mcp320x]) [<7f15e020>] (mcp320x_remove [mcp320x]) from [<8055a8cc>] (spi_drv_remove+0x2c/0x44) [<8055a8cc>] (spi_drv_remove) from [<805087bc>] (__device_release_driver+0x98/0x134) [<805087bc>] (__device_release_driver) from [<80509180>] (driver_detach+0xdc/0xe0) [<80509180>] (driver_detach) from [<8050823c>] (bus_remove_driver+0x5c/0xb0) [<8050823c>] (bus_remove_driver) from [<80509ab0>] (driver_unregister+0x38/0x58) [<80509ab0>] (driver_unregister) from [<7f15e69c>] (mcp320x_driver_exit+0x14/0x1c [mcp320x]) [<7f15e69c>] (mcp320x_driver_exit [mcp320x]) from [<801a78d0>] (SyS_delete_module+0x184/0x1d0) [<801a78d0>] (SyS_delete_module) from [<80108100>] (ret_fast_syscall+0x0/0x1c) Fixes: f5ce4a7a ("iio: adc: add driver for MCP3204/08 12-bit ADC") Cc: Oskar Andero <oskar.andero@gmail.com> Signed-off-by: NLukas Wunner <lukas@wunner.de> Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Zhiyong Tao 提交于
This commit adds mt2712 compatible node. Signed-off-by: NZhiyong Tao <zhiyong.tao@mediatek.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Fabrice Gasnier 提交于
Fix a bad error check when counting 'st,adc-channels' array elements. This is seen when all channels are in use simultaneously. Fixes: 64ad7f64 ("iio: adc: stm32: introduce compatible data cfg") Signed-off-by: NFabrice Gasnier <fabrice.gasnier@st.com> Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Christophe JAILLET 提交于
iio: adc: twl4030: Return an error if we can not enable the vusb3v1 regulator in 'twl4030_madc_probe()' If we can not enable the regulator, go through the error handling path instead of silently continuing. Fixes: 7cc97d77 ("iio: adc: twl4030: Fix ADC[3:6] readings") Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Christophe JAILLET 提交于
iio: adc: twl4030: Disable the vusb3v1 rugulator in the error handling path of 'twl4030_madc_probe()' Commit 7cc97d77 has introduced a call to 'regulator_disable()' in the .remove function. So we should also have such a call in the .probe function in case of error after a successful 'regulator_enable()' call. Add a new label for that and use it. Fixes: 7cc97d77 ("iio: adc: twl4030: Fix ADC[3:6] readings") Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Christophe JAILLET 提交于
If 'devm_regulator_get()' fails, we should go through the existing error handling path instead of returning directly, as done is all the other error handling paths in this function. Fixes: 7cc97d77 ("iio: adc: twl4030: Fix ADC[3:6] readings") Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Lukas Wunner 提交于
Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Lukas Wunner 提交于
The driver sets a .data pointer for each .compatible string but never calls of_device_get_match_data(). Instead, ADC properties are looked up with spi_get_device_id(). The .data pointer is therefore unnecessary, so drop it. Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Lukas Wunner 提交于
Single-channel converters such as mcp3001, mcp3201, mcp3301 and the upcoming mcp3550/1/3 lack a MOSI pin, so there's no need to call mcp320x_channel_to_tx_data() for them. Moreover, instead of calling spi_read() for these converters, which generates an spi_message and spi_transfer on the stack on every readout, it's more efficient to use the spi_message and spi_transfer[] included in struct mcp320x (as we do for multi-channel ADCs), but initialize the spi_message only with the receive transfer. Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 04 9月, 2017 7 次提交
-
-
由 Fabrice Gasnier 提交于
STM32 ADC supports hardware triggers like STM32 Low-Power Timer. For instance, STM32H7 ADC may be triggered by instances 1, 2 or 3. Add hardware triggered mode so Low-Power Timer Trigger driver can validate device. Signed-off-by: NFabrice Gasnier <fabrice.gasnier@st.com> Acked-by: NJonathan Cameron <jic23@kernel.org> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
由 Wolfram Sang 提交于
include/linux/i2c is not for client devices. Move the header file to a more appropriate location. Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: NMark Brown <broonie@kernel.org> Acked-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk> Acked-by: NJonathan Cameron <jic23@kernel.org> Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: NKishon Vijay Abraham I <kishon@ti.com> Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: NThierry Reding <thierry.reding@gmail.com> Acked-by: NTony Lindgren <tony@atomide.com> Acked-by: NDaniel Thompson <daniel.thompson@linaro.org> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
由 Ladislav Michl 提交于
As user's guide "ADS1015EVM, ADS1115EVM, ADS1015EVM-PDK, ADS1115EVM-PDK User Guide (Rev. B)" (http://www.ti.com/lit/ug/sbau157b/sbau157b.pdf) states at page 16: "Note that both the ADS1115 and ADS1015 have internal clocks with a ±10% accuracy. If performing FFT tests, frequencies may appear to be incorrect as a result of this tolerance range.", add those 10% to converion wait time. Cc: Daniel Baluta <daniel.baluta@gmail.com> Cc: Jonathan Cameron <jic23@kernel.org> Signed-off-by: NLadislav Michl <ladis@linux-mips.org> Reviewed-by: NAkinobu Mita <akinobu.mita@gmail.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Ladislav Michl 提交于
There is no point writing ADS1015_CFG_REG when configuration didn't change. Avoid that. Cc: Daniel Baluta <daniel.baluta@gmail.com> Cc: Jonathan Cameron <jic23@kernel.org> Signed-off-by: NLadislav Michl <ladis@linux-mips.org> Reviewed-by: NAkinobu Mita <akinobu.mita@gmail.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Jonathan Cameron 提交于
This has been handled by the spi core for some time now. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk> Reviewed-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Jonathan Cameron 提交于
This has been handled by the i2c core for some time. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
-
由 Akinobu Mita 提交于
The comparator polarity field in config register is not correctly initialized as per the interrupt trigger setting. Because the bitfield definision is wrong and bit shifting is missed. Fixes: d9f39bab ("iio: adc: ti-ads1015: add threshold event support") Cc: Daniel Baluta <daniel.baluta@gmail.com> Cc: Jonathan Cameron <jic23@kernel.org> Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 23 8月, 2017 1 次提交
-
-
由 Jonathan Cameron 提交于
The equivalent of both of these are now done via macro magic when the relevant register calls are made. The actual structure elements will shortly go away. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
-
- 20 8月, 2017 4 次提交
-
-
由 Philipp Zabel 提交于
Commit a53e35db ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit API call so the temporary transition helpers can be removed. No functional changes. Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-iio@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Akinobu Mita 提交于
The ADS1015 device provides programmable comparator that can issue an interrupt on the ALERT pin. This change adds the iio threshold event support for that feature. The ADS1015 device only have a single config register which contains an input multiplexer selection, comparator settings, and etc. So only a single event channel can be enabled at a time. Also enabling both buffer and event are prohibited for simplicity. Cc: Daniel Baluta <daniel.baluta@gmail.com> Cc: Jonathan Cameron <jic23@kernel.org> Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Akinobu Mita 提交于
While the iio buffer for the ti-ads1015 driver is enabled, reading the raw ADC channel data is restricted. We usually use the iio_device_claim_direct_mode()/iio_device_release_direct_mode() pair for that. This change consequently reverses the locking order for the driver's private lock and indio_dev->mlock which acquired by iio_device_claim_direct_mode() internally. But it's safe because there is no other dependency between these locks. Cc: Daniel Baluta <daniel.baluta@gmail.com> Cc: Jonathan Cameron <jic23@kernel.org> Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Akinobu Mita 提交于
Use devm_iio_triggered_buffer_setup to simplify the error path in the probe() and remove() function. This changes the remove order, but the end result of remove function actually does the reverse of probe. Cc: Daniel Baluta <daniel.baluta@gmail.com> Cc: Jonathan Cameron <jic23@kernel.org> Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-