- 23 Oct, 2016 40 commits
-
-
Lars-Peter Clausen authored
Currently the ad7606 driver prints a error message to the kernel log when an application writes an invalid value to a sysfs attribute. While for initial driver development and testing this might be useful it is quite disadvantageous in a production environment. The write() call to the sysfs attribute will already return an error if the value was invalid so the application is aware that the operation failed. And generally speaking it is impossible for an application to reliably match a log message in the kernel log to a specific operation it performed, so the message becomes just noise and might distract from more critical messages. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Lars-Peter Clausen authored
While for some very selected setups it might be useful to be able to provide default configuration data via the platform data, generally this becomes very impractical as the number of configuration options increases. So the general policy is to use the power-on default values of the device and let the application using the device configure it according to its needs. Implement this scheme for the ad7606 driver by removing support for specifying a default configuration via the platform data. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Lars-Peter Clausen authored
The name field in the ad7606_chip_info struct is set to the same value as the as the name field in the corresponding {platform,spi}_device_id table entry. Remove it from the ad7606_chip_info struct and pass the name from the ID to the probe function. This slightly reduces the size of the chip_info table and adding new entries requires less boilerplate. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Lars-Peter Clausen authored
Remove the int_vref_mv field from the ad7606_chip_info struct since the field is never used by the driver. The value is also the same for all derivatives of this chip, so if it will ever be used in the driver a constant value will work just fine. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Eva Rachel Retuya authored
Remove extra parentheses introduced in commit <73e176a tools: iio: iio_generic_buffer: add -A to force-enable all channels>. Suggested-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Eva Rachel Retuya authored
Replace the type of 'force' flag from int to bool and at the same time rename it to 'force_autochannels' for better readability. Suggested-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Lorenzo Bianconi authored
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Lorenzo Bianconi authored
Add support to STM HTS221 humidity + temperature sensor http://www.st.com/resource/en/datasheet/hts221.pdf - continuous mode support - i2c support - spi support - trigger mode support Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Alison Schofield authored
Driver was checking for direct mode but not locking it. Use claim/release helper functions to guarantee the device stays in direct mode during all raw write operations. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Alison Schofield authored
Driver was checking for direct mode but not locking it. Use claim/release helper functions to guarantee the device stays in direct mode during required raw read cases. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Jonathan Cameron authored
Now the driver is in a reasonable state, lets get it (finally) out of staging. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
Basic tidy up of comments to bring them into a standard style. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
Tidied up where checkpatch warning suppressions doesn't effect the readability of the code. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
Previously the device was exposed to userspace and in kernel consumers before the interrupts had been configured. As nothing stopped them being enabled in the interval this could cause unhandled interrupts. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
There seems little point in being able to query the part revision number via sysfs. Hence just put it in the kernel logs during probe incase anyone ever wants to know. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
This is now represented by the standard 3db filter frequency controls. Things get complex wrt to the sampling frequency as these modes change but that is fine under the IIO ABI where any value is allowed to effect any other. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
Also includes an available attribute. The ordering of values appears a bit random, but as the ABI doesn't specify this and we already have both rising and falling lists I think this is fine. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
Given the introduction of IIO_NO_MOD was prior to the first submission prior to IIO entering staging this has been broken for a while. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
Driving towards getting rid of the non standard mode control interface. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
Introduce some more masks and generally drive towards consistent naming. Note the small indents used to indicate parts of registers + parts of multiplexed registers. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
This is an approach used in some newer drivers as it exposes the compound channel events to the core rather than hiding their control in sysfs attributes entirely via the driver. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
In a similar fashion to other newer drivers (e.g. ti_am335x), instead of using the hardware buffer support in IIO to directly access the hardware fifo, insert a software fifo and feed that from the hardware one when interrupts occur. This gives a simpler structure to the data flows and allows more flexibility over how often data is shipped to userspace etc. This was also the only direct user of the simplistic generalization found in ring_hw.h so that header is removed. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
For now we support only the 50% watershed interrupt and start and stop it as part of the buffer bring up. The 75% case may come back in future. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
Not clearing the stuff_to_read flag can lead to a false flag being set on restarting the buffer if the data was not all read the previous time. The size of the scan is needed to ensure the function iio_buffer_read_first_n_outer actually tries to read the data. This stuff has been broken for some time so not stable material. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
This was needed when the buffer support was optional. Pointless wrapper now so drop it. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
In the early days of IIO we were much more inclined to keep the impact of the core IIO elements to the minimum. As time has moved on it has become clear that hardly any builds are done without buffer support and that it adds considerable complexity to the drivers. Hence merge down the buffer and non buffer elements of the sca3000 driver also allowing us to drop the header file used for the interfaces between the two. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Jonathan Cameron authored
Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
-
Brian Masney authored
Move ISL29018/ISL29023/ISL29035 driver out of staging into mainline. Signed-off-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Brian Masney authored
Add ABI documentation from the ISL29018 Data Sheet (FN6619.4, Oct 8, 2012) about the infrared suppression that can be controlled with the proximity_on_chip_ambient_infrared_suppression sysfs attribute. Signed-off-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Alison Schofield authored
Driver was checking for direct mode but not locking it. Use claim/release helper functions to guarantee the device stays in direct mode during raw reads. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Jonathan Cameron authored
Driver was checking for direct mode but not locking it. Use claim/release helper functions to guarantee the device stays in direct mode during all write raw operations. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Alison Schofield authored
Driver was checking for direct mode but not locking it. Use claim/release helper functions to guarantee the device stays in direct mode during raw reads. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Eva Rachel Retuya authored
If attribute/s is/are already enabled (by default or via scripts or manual interaction), issuing -a will fail to enable the channels thereby one has to manually disable the said attribute/s before proceeding with auto-enabling. Add a command-line option -A to force-activate all channels regardless of their current state. Suggested-by: Alison Schofield <amsfield22@gmail.com> Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Tomas Novotny authored
Use a standard framework to get the reference voltage. It is done that way in the iio subsystem and it will simplify extending of the driver. Structure mcp4725_platform_data is left undeleted because it used in the next patch. This change breaks the current users of the driver, but there is no mainline user of struct mcp4725_platform_data. Signed-off-by: Tomas Novotny <tomas@novotny.cz> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Crt Mori authored
Change in handling of the regulator description means that static checkers correctly assume we could be using dereferenced pointer to the regulator. In reality we will never get the -ENODEV error, as current behavior flow does not predict it, because: If the device tree or board file does not define suitable regulators for the component, it will be substituted by a dummy regulator, or, if regulators are disabled altogether, by stubs. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Suggested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Crt Mori <cmo@melexis.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Dan Carpenter authored
The "drivers/" part of the path name was missing. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
sayli karnik authored
There is a type mismatch between the buffer which is of type s16 and the samples stored, which are declared as __le16. Fix the following sparse warning: drivers/iio/imu/bmi160/bmi160_core.c:411:26: warning: incorrect type in assignment (different base types) drivers/iio/imu/bmi160/bmi160_core.c:411:26: expected signed short [signed] [short] [explicitly-signed] <noident> drivers/iio/imu/bmi160/bmi160_core.c:411:26: got restricted __le16 [addressable] [usertype] sample This is a cosmetic-type patch since it does not alter code behaviour. The le16 is going into a 16bit buf element, and is labelled as IIO_LE in the channel buffer definition. Signed-off-by: sayli karnik <karniksayli1995@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Brian Masney authored
Rename description from "ISL 29018" to "Intersil 29018" in Kconfig for consistency with other drivers in mainline. Signed-off-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Brian Masney authored
Remove blank line between MODULE_DEVICE_TABLE() and its corresponding structure for consistency with the other device table entries. Signed-off-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-