Previous offset wasn't applied in the correct order and invalid.
This patchset fixes this issue, and also has the correct scale value
applied to the offset.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Support for MS8607 temperature, pressure & humidity sensor.
This part is using functions from MS5637 for temperature and pressure
and HTU21 for humidity
Signed-off-by: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Support for HTU21 temperature & humidity sensor
Signed-off-by: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Add support for the HDC100x temperature and humidity sensors
including the resistive heater element.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The maximum possible value for the relative humidity is 55575 (100%RH).
This value, if shifted right by 2 bits, uses 14 bits and masking it with
a 12 bit mask removes 2 meaningful bits.
The masking has been replaced with a range check that sets the minimum
value at 786 (0%RH) and the maximum at 13893 (99.998%RH).
Signed-off-by: Nicola Corna <nicola@corna.info>
Reviewed-by: Hartmut Knaack <knaack.h@gmx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This cleans up the most ugly workaround in this driver. There are no
functional changes yet in the decoding algorithm, but we improve the
following things:
* Get rid of spurious warning messages on systems with fast HRTIMER.
* If the clock is not fast enough for decoding to work, we give
up immediately.
* In that case we return EAGAIN instead of EIO, so it's easier to
discriminate causes of failure.
Returning EAGAIN is somewhat controversial: It's technically correct
as a faster clock might become available. OTOH once all clocks are
enabled this is a permanent error. There is no ECLOCKTOOSLOW error
code.
Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* add spaces around binary operators in cases where it reduces readability
* align multiline statements around opening parenthesis
Reported-by: Hartmut Knaack <knaack.h@gmx.de>
in Message-ID: <55919E72.3010807@gmx.de>
Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is
not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer
functionality only, can still be compiled if GPIOLIB is not enabled.
Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where
appropriate.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Since only a pointer to struct i2c_client is stored in a private area
of IIO device created by the driver there's no need to allocate
sizeof(struct i2c_client) worth of storage.
Pushed to stable as this is linked to the revert patch previously.
Without this followup the original patch looks sensible.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Stable@vger.kernel.org
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This reverts commit e0922e5e3c.
Requested by Andrey Smirnov.
It incorrectly assumes that the level of indirection is not needed
which is not true(probably because the driver incorrectly allocates
sizeof(*client) instead of sizeof(*data) via devm_iio_device_alloc).
If you look at the code of the probe function(see below) it is easy to
see that what is being stored in the private memory of the IIO device
instance is not a copy of a 'struct i2c_client' but a pointer to an
instance passed as an argument to the probe function.
struct i2c_client **data;
int ret;
< Some code skipped >
indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*client));
if (!indio_dev)
return -ENOMEM;
data = iio_priv(indio_dev);
*data = client;
Without reverting this change any read of a raw value of this sensor
leads to a kernel oops due to a NULL pointer de-reference on my
hardware setup.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Stable@vger.kernel.org
Since setting irq-enabled GPIOs into output state is not supported
by all GPIO controllers, we need to disable the irq while requesting
sensor data. As side effect we lose a tiny bit of functionality:
Some wiring problems can't be concluded from log messages anymore.
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Make sure that the read function is not interrupted...
Signed-off-by: Richard Weinberger <richard@nod.at>
Acked-by: Harald Geyer <harald@ccbib.org>
Reviewed-by: Sanjeev Sharma <sanjeev_sharma@mentor.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
As we access i-1 we must not start with i=0.
Signed-off-by: Richard Weinberger <richard@nod.at>
Acked-by: Hartmut Knaack <knaack.h@gmx.de>
Acked-by: Harald Geyer <harald@ccbib.org>
Reviewed-by: Sanjeev Sharma <sanjeev_sharma@mentor.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
In si7020_read_raw() the pointer to the i2c client was obtained as second level
pointer, although a simple pointer is appropriate.
Signed-off-by: Hartmut Knaack <knaack.h@gmx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
When reading temperature or humidity values, a shift of two bits to the right
needs to be applied, and only for the humidity channel a mask of the lower
12 bits needs to be applied. This reduces code repetition.
During probe, i2c_set_clientdata() was used, although its counterpart was not,
so drop it.
Signed-off-by: Hartmut Knaack <knaack.h@gmx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch adds support to the Industrial IO subsystem
for the Silicon Labs Si7013/20/21 Relative Humidity and
Temperature Sensors.
Website: http://www.silabs.com/products/sensors/humidity-sensors/Pages/si7013-20-21.aspx
These are i2c devices which measure relative humidity
and temperature and all use the same protocol. The
Si7013 has an additional input with programmable
linearization which is not supported because that's
complicated and I didn't need it.
Signed-off-by: David Barksdale <dbarksdale@uplogix.com>
--
Changes since v1:
* Renamed to si7020 and replaced Si701x/2x with Si7013/20/21.
* Removed unneeded mutex.
* Pre-computed floating-point constant expressions.
* Removed address_list and I2C_CLASS_HWMON.
Changes since v2:
* Return correct raw sensor values.
* Rename dev variable to indio_dev.
* Issue a software reset command during probe.
* Un-broke string literal.
Changes since v3:
* enum changed to #define
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch removes the .owner field for drivers which use the
platform_driver_register api because this is overriden in
_platform_driver_register.
Signed-off-by: Sanjeev Sharma <Sanjeev_Sharma@mentor.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
sensor provides 12-bit relative humidity and 14-bit temperature
via I2C interface; temperature and linearity compensation is not
implemented (yet)
driver also supports the Si7015, but not the 2nd generation
sensors Si7013/Si7020/Si7021
datasheet is here
http://www.silabs.com/Support%20Documents/TechnicalDocs/Si7005.pdf
v2: (thanks to Lars-Peter Clausen)
* fix coding style
* use devm_iio_device_register()
* change copyright year to 2014
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Matt Ranostay