- Mar 19, 2017
-
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org>
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by:
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by:
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by:
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by:
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by:
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by:
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by:
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by:
Crt Mori <cmo@melexis.com> Acked-by:
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by:
-
Miguel Robles authored
Fix checkpatch warnings: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' Signed-off-by:
Miguel Robles <miguel.robles@farole.net> Signed-off-by:
-
Aishwarya Pant authored
In the driver adis16201 read raw does not require an iio_dev->mlock for reads. It can run concurrently as adis_read_reg_16() is protected by a transaction lock. Signed-off-by:
Aishwarya Pant <aishpant@gmail.com> Signed-off-by:
-
- Mar 18, 2017
-
-
Varsha Rao authored
Remove mutex_lock() and mutex_unlock() function calls, as the adis16240_spi_read_signed() function can be run parallel and safely multiple times. Also remove the mutex.h header file and comment, which are no longer required. As indio_dev is declared and initialized in adis16240_spi_read_signed(), again declaration to same type and initialization to same value is not required, remove it from adis16240_read_12bit_signed(). Simplify the return logic, by merging assignment and return into a single line. Signed-off-by:
Varsha Rao <rvarsha016@gmail.com> Signed-off-by:
-
- Mar 16, 2017
-
-
sayli karnik authored
The patch removes unnecessary use of goto statement. Signed-off-by:
sayli karnik <karniksayli1995@gmail.com> Signed-off-by:
-
sayli karnik authored
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:
-
Miguel Robles authored
Fix checkpatch warnings: Symbolic permissions are not preferred. Consider using octal permissions. Signed-off-by:
-
William Breathitt Gray authored
PC/104 drivers should be hidden on machines which do not support PC/104 devices. This patch adds the PC104 Kconfig option as a dependency for the relevant PC/104 device driver Kconfig options. 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> Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by:
-
Aishwarya Pant authored
The IIO subsystem is redefining iio_dev mlock to be used by IIO core only for protecting device operating mode changes. In driver ad7746 wherever mlock was used to protect hardware state changes, it has been replaced with a driver private lock. Signed-off-by:
-
- Mar 14, 2017
-
-
Narcisa Ana Maria Vasile authored
Group the scan indexes into an enum. Signed-off-by:
Narcisa Ana Maria Vasile <narcisaanamaria12@gmail.com> Signed-off-by:
-
Narcisa Ana Maria Vasile authored
Group the scan indexes into an enum. Signed-off-by:
-
simran singhal authored
Remove & from function pointers to conform to the style preferred in IIO. (Note that this is fine in staging drivers, but would create too much churn to do outside of staging, unless otherwise working on a driver). Done using the following semantic patch // <smpl> @r@ identifier f; @@ f(...) { ... } @@ identifier r.f; @@ - &f + f // </smpl> Signed-off-by:simran singhal <singhalsimran0@gmail.com> Signed-off-by:
-
simran singhal authored
Remove & from function pointers to conform to the style found in the wider subsystem. Done using the following semantic patch // <smpl> @r@ identifier f; @@ f(...) { ... } @@ identifier r.f; @@ - &f + f // </smpl> Signed-off-by: -
simran singhal authored
Remove & from function pointers to conform to the style found elsewhere in the file. Done using the following semantic patch // <smpl> @r@ identifier f; @@ f(...) { ... } @@ identifier r.f; @@ - &f + f // </smpl> Signed-off-by: -
simran singhal authored
Remove & from function pointers to conform to the style found elsewhere in the file. Done using the following semantic patch // <smpl> @r@ identifier f; @@ f(...) { ... } @@ identifier r.f; @@ - &f + f // </smpl> Signed-off-by: -
simran singhal authored
Remove & from function pointers to conform to the style found elsewhere in the file. Done using the following semantic patch // <smpl> @r@ identifier f; @@ f(...) { ... } @@ identifier r.f; @@ - &f + f // </smpl> Signed-off-by: -
simran singhal authored
Remove & from function pointers to conform to the style found elsewhere in the file. Done using the following semantic patch // <smpl> @r@ identifier f; @@ f(...) { ... } @@ identifier r.f; @@ - &f + f // </smpl> Signed-off-by: -
simran singhal authored
Remove & from function pointers to conform to the style found elsewhere in the file. Done using the following semantic patch // <smpl> @r@ identifier f; @@ f(...) { ... } @@ identifier r.f; @@ - &f + f // </smpl> Signed-off-by: -
simran singhal authored
Remove & from function pointers to conform to the style found elsewhere in the file. Done using the following semantic patch // <smpl> @r@ identifier f; @@ f(...) { ... } @@ identifier r.f; @@ - &f + f // </smpl> Signed-off-by: -
simran singhal authored
Remove & from function pointers to conform to the style found elsewhere in the file. Done using the following semantic patch // <smpl> @r@ identifier f; @@ f(...) { ... } @@ identifier r.f; @@ - &f + f // </smpl> Signed-off-by: -
simran singhal authored
Remove & from function pointers to conform to the style found elsewhere in the file. Done using the following semantic patch // <smpl> @r@ identifier f; @@ f(...) { ... } @@ identifier r.f; @@ - &f + f // </smpl> Signed-off-by: -
sayli karnik authored
The contents of ade7754.h are only used in ade7754.c. Move the header contents to the source file and delete the header file. Signed-off-by:
-
Alison Schofield authored
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:
-
- Mar 12, 2017
-
-
Bo Yu authored
The following Coccinelle script was used to detect this: @@ local idexpression ret; expression e; @@ -ret = +return e; -return ret; Signed-off-by:Bo YU <tsu.yubo@gmail.com> Signed-off-by:
-
sayli karnik authored
The contents of ade7759.h are only used in ade7759.c. Move the header contents to the source file and delete the header file. Signed-off-by:
-
- Mar 09, 2017
-
-
Quentin Schulz authored
The Allwinner SoCs all have an ADC that can also act as a touchscreen controller and a thermal sensor. This patch adds the ADC driver which is based on the MFD for the same SoCs ADC. This also registers the thermal adc channel in the iio map array so iio_hwmon could use it without modifying the Device Tree. This registers the driver in the thermal framework. The thermal sensor requires the IP to be in touchscreen mode to return correct values. Therefore, if the user is continuously reading the ADC channel(s), the thermal framework in which the thermal sensor is registered will switch the IP in touchscreen mode to get a temperature value and requires a delay of 100ms (because of the mode switching), then the ADC will switch back to ADC mode and requires also a delay of 100ms. If the ADC readings are critical to user and the SoC temperature is not, this driver is capable of not registering the thermal sensor in the thermal framework and thus, "quicken" the ADC readings. This driver probes on three different platform_device_id to take into account slight differences (registers bit and temperature computation) between Allwinner SoCs ADCs. Signed-off-by:
Quentin Schulz <quentin.schulz@free-electrons.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Wolfram Sang authored
Due to RST rework, the reference to i2c/trivial-devices was changed, but the result is broken. However, let's just drop the whole reference, since it doesn't make sense in the first place to reference this "global" file for a single driver. Fixes: 8c27ceff ("docs: fix locations of several documents that got moved") Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com> Cc: Kevin Tsai <ktsai@capellamicro.com> Cc: Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Wei Yongjun authored
Remove .owner field if calls are used which set it automatically. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
- Mar 08, 2017
-
-
Alan Cox authored
Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
This cuts it back to what is basically a few wrapper functions. At some point we can kill most of these too by changing the callers. Signed-off-by:
-
