Datasheet specifies typical and maximum execution times for which CMD
register is occupied after previous command execution. We took these
values as minimum and maximum time for usleep_range() call before making
a new command execution.

To be sure, that the CMD register is no longer occupied we need to wait
*at least* the maximum time specified by datasheet.
Signed-off-by: NMarcin Niestroj <m.niestroj@grinn-global.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The set_to_preset_on_index sysfs attribute provides a boolean
configuration option to enable a preset operation on the respective
channel's counter when Index occurs. However, the corresponding
configuration bit on the Input/Output Control register must be set low
to enable the preset operation.

This patch inverts the internal driver boolean logic exposed via the
set_to_preset_on_index attribute in order to correctly configure the
device which expects an active low bit.

Fixes: 28e5d3bb ("iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8")
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The Input/Output Control register (IOR) is offset by 1 from the
respective channel data register. This patch fixes off-by-one errors
when attempting to write to a channel IOR where the base address was not
properly offset.

Fixes: 28e5d3bb ("iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8")
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The LS7266R1 requires bits 5 & 6 to be high in order to select the Index
Control Register. This patch fixes a typo that incorrectly selects the
Input/Output Control Register where the Index Control Register was
desired.

Fixes: 28e5d3bb ("iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8")
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

iio: magnetometer: separate the values of attributes based on their usage type for HID compass sensor

There are 2 usage types (Magnetic Flux and Heading data field) for HID
compass sensor, thus the values of offset, scale, and sensitivity should
be separated according to their respective usage type. The changes made
are as below:
1. Hysteresis: A struct hid_sensor_common rot_attributes is created in
struct magn_3d_state to contain the sensitivity for IIO_ROT.
2. Scale: scale_pre_decml and scale_post_decml are separated for IIO_MAGN
and IIO_ROT.
3. Offset: Same as scale, value_offset is separated for IIO_MAGN and
IIO_ROT.

For sensitivity, HID_USAGE_SENSOR_ORIENT_MAGN_FLUX and
HID_USAGE_SENSOR_ORIENT_MAGN_HEADING are used for sensivitity fields based
on the HID Sensor Usages specifications. Hence, these changes are added on
the sensitivity field.
Signed-off-by: NOoi, Joyce <joyce.ooi@intel.com>
Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

This array is supposed to have 10 elements.  Smatch complains that with
the current code we can have n == max_ints and read beyond the end of
the array.

Fixes: ac4f6eee ("staging: iio: TAOS tsl258x: Device driver")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NBrian Masney <masneyb@onstation.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

We have #defines for all the individual sensor registers and
value/mask pairs #defined at the top of the file and used at
exactly one spot.

This is usually good if the #defines give a meaning to the
opaque magic numbers.

However in this case, the semantic meaning is inherent in the
name of the C99-addressable fields, and that means duplication
of information, and only makes the code hard to maintain since
you every time have to add a new #define AND update the site
where it is to be used.

Get rid of the #defines and just open code the values into the
appropriate struct elements. Make sure to explicitly address
the .hz and .value fields in the st_sensor_odr_avl struct
so that the meaning of all values is clear.

This patch is purely syntactic should have no semantic effect.

Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NLorenzo Bianconi <lorenzo.bianconi@st.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

This patch adds support for STMicroelectronics STM32 MCU's analog to
digital converter.
Signed-off-by: NFabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Add core driver for STMicroelectronics STM32 ADC (Analog to Digital
Converter). STM32 ADC can be composed of up to 3 ADCs with shared
resources like clock prescaler, common interrupt line and analog
reference voltage.
This core driver basically manages shared resources.
Signed-off-by: NFabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Move tsl2580, tsl2581, tsl2583 driver out of staging into mainline.
Signed-off-by: NBrian Masney <masneyb@onstation.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The DAC is used to find the peak level of an alternating voltage input
signal by a binary search using the output of a comparator wired to
an interrupt pin. Like so:
                          _
                         | \
    input +------>-------|+ \
                         |   \
           .-------.     |    }---.
           |       |     |   /    |
           |    dac|-->--|- /     |
           |       |     |_/      |
           |       |              |
           |       |              |
           |    irq|------<-------'
           |       |
           '-------'
Signed-off-by: NPeter Rosin <peda@axentia.se>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

It is assumed that the dpot is used as a voltage divider between the
current dpot wiper setting and the maximum resistance of the dpot. The
divided voltage is provided by a vref regulator.

                  .------.
   .-----------.  |      |
   | vref      |--'    .---.
   | regulator |--.    |   |
   '-----------'  |    | d |
                  |    | p |
                  |    | o |  wiper
                  |    | t |<---------+
                  |    |   |
                  |    '---'       dac output voltage
                  |      |
                  '------+------------+
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Example:

$ cat '/sys/bus/iio/devices/iio:device0/out_resistance_raw_available'
[0 1 256]

Meaning: min 0, step 1 and max 256.
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Specifically a helper for reading the available maximum raw value of a
channel and a helper for forwarding read_avail requests for raw values
from one iio driver to an iio channel that is consumed.

These rather specific helpers are in turn built with generic helpers
making it easy to build more helpers for available values as needed.
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

A large number of attributes can only take a limited range of values.
Currently in IIO this is handled by directly registering additional
*_available attributes thus providing this information to userspace.

It is desirable to provide this information via the core for much the same
reason this was done for the actual channel information attributes in the
first place.  If it isn't there, then it can only really be accessed from
userspace.  Other in kernel IIO consumers have no access to what valid
parameters are.

Two forms are currently supported:
* list of values in one particular IIO_VAL_* format.
	e.g. 1.300000 1.500000 1.730000
* range specification with a step size:
	e.g. [1.000000 0.500000 2.500000]
	equivalent to 1.000000 1.5000000 2.000000 2.500000

An addition set of masks are used to allow different sharing rules for the
*_available attributes generated.

This allows for example:

in_accel_x_offset
in_accel_y_offset
in_accel_offset_available.

We could have gone with having a specification for each and every
info_mask element but that would have meant changing the existing userspace
ABI.  This approach does not.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
[forward ported, added some docs and fixed buffer overflows /peda]
Acked-by: NDaniel Baluta <daniel.baluta@intel.com>
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

As found by gcc -Wmaybe-uninitialized, having a storage_bytes value other
than 2 or 4 will result in undefined behavior:

drivers/iio/temperature/maxim_thermocouple.c: In function 'maxim_thermocouple_read':
drivers/iio/temperature/maxim_thermocouple.c:141:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This probably cannot happen, but returning -EINVAL here is appropriate
and makes gcc happy and the code more robust.

Fixes: 231147ee ("iio: maxim_thermocouple: Align 16 bit big endian value of raw reads")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
(cherry picked from commit 32cb7d27)
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We have #defines for all the individual sensor registers and
value/mask pairs #defined at the top of the file and used at
exactly one spot.

This is usually good if the #defines give a meaning to the
opaque magic numbers.

However in this case, the semantic meaning is inherent in the
name of the C99-addressable fields, and that means duplication
of information, and only makes the code hard to maintain since
you every time have to add a new #define AND update the site
where it is to be used.

Get rid of the #defines and just open code the values into the
appropriate struct elements. Make sure to explicitly address
the .hz and .value fields in the st_sensor_odr_avl struct
so that the meaning of all values is clear.

This patch is purely syntactic should have no semantic effect.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

We have #defines for all the individual sensor registers and
value/mask pairs #defined at the top of the file and used at
exactly one spot.

This is usually good if the #defines give a meaning to the
opaque magic numbers.

However in this case, the semantic meaning is inherent in the
name of the C99-addressable fields, and that means duplication
of information, and only makes the code hard to maintain since
you every time have to add a new #define AND update the site
where it is to be used.

Get rid of the #defines and just open code the values into the
appropriate struct elements. Make sure to explicitly address
the .hz and .value fields in the st_sensor_odr_avl struct
so that the meaning of all values is clear.

This patch is purely syntactic should have no semantic effect.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

We have #defines for all the individual sensor registers and
value/mask pairs #defined at the top of the file and used at
exactly one spot.

This is usually good if the #defines give a meaning to the
opaque magic numbers.

However in this case, the semantic meaning is inherent in the
name of the C99-addressable fields, and that means duplication
of information, and only makes the code hard to maintain since
you every time have to add a new #define AND update the site
where it is to be used.

Get rid of the #defines and just open code the values into the
appropriate struct elements. Make sure to explicitly address
the .hz and .value fields in the st_sensor_odr_avl struct
so that the meaning of all values is clear.

This patch is purely syntactic should have no semantic effect.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The i2c mux core can then take appropriate action depending on if it is
used for an actual i2c mux, or for an arbitrator or gate. In this case
it is used as a gate.

This will make devicetree bindings simpler when they are eventually
added.
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

status is a u8 hence the check if status is less than zero has no effect.
Fix this by replacing status with int ret so the less than zero compare
will correctly detect errors.

Issue found with static analysis with CoverityScan, CID 1375919
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Fixes: 974e6f02 ("iio: cros_ec_sensors_core: Add common functions for the ChromeOS EC Sensor Hub")
Reviewed-by: NGuenter Roeck <groeck@chromium.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

We should be testing "ret" here.

Fixes: aa16c6bd ("iio:adc: Add support for AD7766/AD7767")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The new mpu3050 driver fails to build if I2C is disabled:

drivers/iio/built-in.o: In function `mpu3050_i2c_driver_exit':
mpu3050-i2c.c:(.exit.text+0x17f): undefined reference to `i2c_del_driver'
drivers/iio/built-in.o: In function `mpu3050_i2c_driver_init':
mpu3050-i2c.c:(.init.text+0x215): undefined reference to `i2c_register_driver'

This adds a Kconfig dependency to ensure we only build it when I2C
is available.

Fixes: 3904b28e ("iio: gyro: Add driver for the MPU-3050 gyroscope")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The newly added mpu3050 driver has two initializations for the
module owner, which causes a warning for 'make W=1':

include/linux/export.h:37:21: error: initialized field overwritten [-Werror=override-init]
drivers/iio/gyro/mpu3050-core.c:749:19: note: in expansion of macro 'THIS_MODULE'

This removes one of the two.

Fixes: 3904b28e ("iio: gyro: Add driver for the MPU-3050 gyroscope")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

While testing, it was observed that on some platforms the scale value
from iio sysfs for gyroscope is always 0 (E.g. Yoga 260). This results
in the final angular velocity component values to be zeros.

This is caused by insufficient precision of scale value displayed in sysfs.
If the precision is changed to nano from current micro, then this is
sufficient to display the scale value on this platform.
Since this can be a problem for all other HID sensors, increase scale
precision of all HID sensors to nano from current micro.

Results on Yoga 260:

name		scale before	scale now
--------------------------------------------
gyro_3d		0.000000	0.000000174
als			0.001000	0.001000000
magn_3d		0.000001	0.000001000
accel_3d		0.000009	0.000009806
Signed-off-by: NSong Hongyan <hongyan.song@intel.com>
Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

This fix makes newer ISH hubs work. Previous ones worked by lucky
coincidence.

Rotation sensor function does not work due to miss PM function.
Add common hid sensor iio pm function for rotation sensor.

Further clarification from Srinivas:

If CONFIG_PM is not defined, then this prevents this sensor to
function. So above commit caused this.

This sensor was supposed to be always on to trigger wake up in prior
external hubs. But with the new ISH hub this is not the case.
Signed-off-by: NSong Hongyan <hongyan.song@intel.com>
Fixes: 2b89635e ("iio: hid_sensor_hub: Common PM functions")
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

This patch adds the required pieces to ti_am335x_adc driver for
DMA support
Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Add suspend/resume callback, support the pinctrl sleep state when
the system suspend as well.
Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com>
Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Neither sample frequency value nor hysteresis value can be set to be a
negative number, check and return "Invalid argument" if they are negative.

If not do this change, sample_frequency will be set into some unknown
value, read hysteresis value after write negative number will return
"Invalid argument".
Signed-off-by: NSong Hongyan <hongyan.song@intel.com>
Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

add support to STMicroelectronics LNG2DM accelerometer to
st_accel framework
Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@st.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

This adds devicetree support for the si7020 iio driver. Since it works
well without requiring any additional property, its compatible string is
added to the trivial i2c devices bindings list.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Remove duplicated include.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Would have merged this into the original patch as a fixup but I've already
pushed that out as an immutable branch for others to use so it'll have
to be a separate patch.  The original select had a typo as well.

Trying to do this via a select was opening a can of worms due to
a tree of other elements that would also have needed selecting.
A simple depends seems much mroe straight forward and appropriate in this
case.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>

fix scale configuration/parsing for h3lis331dl accel driver
when sensitivity is higher than 1(m/s^2)/digit
Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@st.com>
Fixes: 1e52fefc ("iio: accel: Add support for the h3lis331dl accelerometer")
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Check whether the ChromeOS Embedded Controller is a sensor hub and in
such case issue a command to get the number of sensors and register them
all.
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: NGuenter Roeck <groeck@chromium.org>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Handle 3d contiguous sensors like Accelerometers, Gyroscope and
Magnetometer that are presented by the ChromeOS EC Sensor hub.
Signed-off-by: NGuenter Roeck <groeck@chromium.org>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Add the core functions to be able to support the sensors attached behind
the ChromeOS Embedded Controller and used by other IIO cros-ec sensor
drivers.

The cros_ec_sensor_core driver matches with current driver in ChromeOS
4.4 tree, so it includes all the fixes at the moment. The support for
this driver was made by Gwendal Grignou. The original patch and all the
fixes has been squashed and rebased on top of mainline.
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NGuenter Roeck <groeck@chromium.org>
[eballetbo: split, squash and rebase on top of mainline the patches
found in ChromeOS tree]
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

As found by gcc -Wmaybe-uninitialized, having a storage_bytes value other
than 2 or 4 will result in undefined behavior:

drivers/iio/temperature/maxim_thermocouple.c: In function 'maxim_thermocouple_read':
drivers/iio/temperature/maxim_thermocouple.c:141:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This probably cannot happen, but returning -EINVAL here is appropriate
and makes gcc happy and the code more robust.

Fixes: 231147ee ("iio: maxim_thermocouple: Align 16 bit big endian value of raw reads")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

This adds a new driver for the Invensense MPU-3050 gyroscope.
This driver is based on information from the rough input driver
in drivers/input/misc/mpu3050.c and the scratch misc driver
posted by Nathan Royer in 2011. Some years have passed but this
is finally a fully-fledged driver for this gyroscope. It was
developed and tested on the Qualcomm APQ8060 Dragonboard.

The driver supports both raw and buffered input. It also
supports the internal trigger mechanism by registering a trigger
that can fire in response to the internal sample engine of the
component. In addition to reading out the gyroscope sensor
values, the driver also supports reading the temperature from
the sensor.

The driver currently only supports I2C but the MPU-3050 can
also be used from SPI, so the I2C portions are split in their
own file and we just use regmap to access all registers, so
it will be trivial to plug in SPI support if/when someone has
a system requiring this.

To conserve power, the driver utilizes the runtime PM
framework and will put the sensor in off mode and disable the
regulators when unused, after a timeout of 10 seconds.

The fullscale can be set for the sensor to 250, 500, 1000 or
2000 deg/s. This corresponds to scale values of rougly 0.000122,
0.000275, 0.000512 or 0.001068. By writing such values (or close
to these) into "in_anglevel_scale", the corresponding fullscale
can be chosen. It will default to 2000 deg/s (~35 rad/s).

The gyro component can have DC offsets on all axes. These can be
compensated using the standard sysfs ABI property
"in_anglevel_[xyz]_calibbias". This is in positive/negative
values of the raw values, so a suitable calibration bias can be
determined by userspace by reading the "in_anglevel_[xyz]_raw"
for a few iterations while holding the sensor still, create an
average integer, and writing the negative inverse of that into
"in_anglevel_[xyz]_calibbias". After this the hardware will
automatically subtract the bias, also when using buffered
readings.

Since the MPU-3050 has an outgoing I2C port it needs to act as
an I2C mux. This means that the device is switching I2C traffic
to devices beyond it. On my system this is the only way to reach
the accelerometer. The "sensor fusion" ability of the MPU-3050
to directly talk to the device on the outgoing I2C port is
currently not used by the driver, but it has code to allow I2C
traffic to pass through so that the Linux kernel can reach the
device on the other side with a kernel driver.

Example usage with the native trigger:

$ generic_buffer -a -c10 -n mpu3050
iio device number being used is 0
iio trigger number being used is 0
No channels are enabled, enabling all channels
Enabling: in_anglvel_z_en
Enabling: in_timestamp_en
Enabling: in_anglvel_y_en
Enabling: in_temp_en
Enabling: in_anglvel_x_en
/sys/bus/iio/devices/iio:device0 mpu3050-dev0
29607.142578 -0.117493 0.074768 0.012817 180788797150
29639.285156 -0.117493 0.076904 0.013885 180888982335
29696.427734 -0.116425 0.076904 0.012817 180989178039
29742.857422 -0.117493 0.076904 0.012817 181089377742
29764.285156 -0.116425 0.077972 0.012817 181189574187
29860.714844 -0.115356 0.076904 0.012817 181289772705
29864.285156 -0.117493 0.076904 0.012817 181389971520
29910.714844 -0.115356 0.076904 0.013885 181490170483
29917.857422 -0.116425 0.076904 0.011749 181590369742
29975.000000 -0.116425 0.076904 0.012817 181690567075
Disabling: in_anglvel_z_en
Disabling: in_timestamp_en
Disabling: in_anglvel_y_en
Disabling: in_temp_en
Disabling: in_anglvel_x_en

The first column is the temperature in millidegrees, then the x,y,z
axes in succession followed by the timestamp. Also tested successfully
using the HRTimer trigger.

Cc: Nick Vaccaro <nvaccaro@google.com>
Cc: Ge Gao <ggao@invensense.com>
Cc: Anna Si <asi@invensense.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Crestez Dan Leonard <leonard.crestez@intel.com>
Cc: Daniel Baluta <daniel.baluta@intel.com>
Cc: Gregor Boirie <gregor.boirie@parrot.com>
Cc: Peter Rosin <peda@axentia.se>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

This will result in a random value being reported on big endian architectures.
(thanks to Lars-Peter Clausen for pointing out the effects of this bug)

Only effects a value printed to the log, but as this reports the settings of
the probe in question it may be of direct interest to users.

Also, fixes the following sparse endianness warnings:

drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
Signed-off-by: NSandhya Bankar <bankarsandhya512@gmail.com>
Fixes: e8dd92bf ("iio: chemical: atlas-ph-sensor: add EC feature")
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>