kernel/linux.git/drivers/iio/common, branch v4.4.235

iio: common: ssp_sensors: Initialize calculated_time in ssp_common_process_data

2019-06-11T10:24:02+00:00

[ Upstream commit 6f9ca1d3eb74b81f811a87002de2d51640d135b1 ] When building with -Wsometimes-uninitialized, Clang warns: drivers/iio/common/ssp_sensors/ssp_iio.c:95:6: warning: variable 'calculated_time' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] While it isn't wrong, this will never be a problem because iio_push_to_buffers_with_timestamp only uses calculated_time on the same condition that it is assigned (when scan_timestamp is not zero). While iio_push_to_buffers_with_timestamp is marked as inline, Clang does inlining in the optimization stage, which happens after the semantic analysis phase (plus inline is merely a hint to the compiler). Fix this by just zero initializing calculated_time. Link: https://github.com/ClangBuiltLinux/linux/issues/394 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: hid-sensor-trigger: Fix the race with user space powering up sensors

2017-08-30T08:19:27+00:00

commit f1664eaacec31035450132c46ed2915fd2b2049a upstream. It has been reported for a while that with iio-sensor-proxy service the rotation only works after one suspend/resume cycle. This required a wait in the systemd unit file to avoid race. I found a Yoga 900 where I could reproduce this. The problem scenerio is: - During sensor driver init, enable run time PM and also set a auto-suspend for 3 seconds. This result in one runtime resume. But there is a check to avoid a powerup in this sequence, but rpm is active - User space iio-sensor-proxy tries to power up the sensor. Since rpm is active it will simply return. But sensors were not actually powered up in the prior sequence, so actaully the sensors will not work - After 3 seconds the auto suspend kicks If we add a wait in systemd service file to fire iio-sensor-proxy after 3 seconds, then now everything will work as the runtime resume will actually powerup the sensor as this is a user request. To avoid this: - Remove the check to match user requested state, this will cause a brief powerup, but if the iio-sensor-proxy starts immediately it will still work as the sensors are ON. - Also move the autosuspend delay to place when user requested turn off of sensors, like after user finished raw read or buffer disable Signed-off-by: Srinivas Pandruvada Tested-by: Bastien Nocera Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3

2017-03-30T07:35:17+00:00

commit 3bec247474469f769af41e8c80d3a100dd97dd76 upstream. In function _hid_sensor_power_state(), when hid_sensor_read_poll_value() is called, sensor's all properties will be updated by the value from sensor hardware/firmware. In some implementation, sensor hardware/firmware will do a power cycle during S3. In this case, after resume, once hid_sensor_read_poll_value() is called, sensor's all properties which are kept by driver during S3 will be changed to default value. But instead, if a set feature function is called first, sensor hardware/firmware will be recovered to the last status. So change the sensor_hub_set_feature() calling order to behind of set feature function to avoid sensor properties lose. Signed-off-by: Song Hongyan Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: hid-sensors: Increase the precision of scale to fix wrong reading interpretation.

2016-11-18T09:48:35+00:00

commit 6f77199e9e4b84340c751c585691d7642a47d226 upstream. 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: Song Hongyan Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: fix pressure data output unit in hid-sensor-attributes

2016-09-24T08:07:38+00:00

commit 36afb176d3c9580651d7f410ed7f000ec48b5137 upstream. According to IIO ABI definition, IIO_PRESSURE data output unit is kilopascal: http://lxr.free-electrons.com/source/Documentation/ABI/testing/sysfs-bus-iio This patch fix output unit of HID pressure sensor IIO driver from pascal to kilopascal to follow IIO ABI definition. Signed-off-by: Kweh, Hock Leong Reviewed-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

Merge tag 'spi-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

2015-11-05T21:15:12+00:00

Pull spi updates from Mark Brown: "Quite a lot of activity in SPI this cycle, almost all of it in drivers with a few minor improvements and tweaks in the core. - Updates to pxa2xx to support Intel Broxton and multiple chip selects. - Support for big endian in the bcm63xx driver. - Multiple slave support for the mt8173 - New driver for the auxiliary SPI controller in bcm2835 SoCs. - Support for Layerscale SoCs in the Freescale DSPI driver" * tag 'spi-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (87 commits) spi: pxa2xx: Rework self-initiated platform data creation for non-ACPI spi: pxa2xx: Add support for Intel Broxton spi: pxa2xx: Detect number of enabled Intel LPSS SPI chip select signals spi: pxa2xx: Add output control for multiple Intel LPSS chip selects spi: pxa2xx: Use LPSS prefix for defines that are Intel LPSS specific spi: Add DSPI support for layerscape family spi: ti-qspi: improve ->remove() callback spi/spi-xilinx: Fix race condition on last word read spi: Drop owner assignment from spi_drivers spi: Add THIS_MODULE to spi_driver in SPI core spi: Setup the master controller driver before setting the chipselect spi: dw: replace magic constant by DW_SPI_DR spi: mediatek: mt8173 spi multiple devices support spi: mediatek: handle controller_data in mtk_spi_setup spi: mediatek: remove mtk_spi_config spi: mediatek: Update document devicetree bindings to support multiple devices spi: fix kernel-doc warnings about missing return desc in spi.c spi: fix kernel-doc warnings about missing return desc in spi.h spi: pxa2xx: Align a few defines spi: pxa2xx: Save other reg_cs_ctrl bits when configuring chip select ...

spi: Drop owner assignment from spi_drivers

2015-10-28T01:30:17+00:00

An spi_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Andrew F. Davis Acked-by: Jonathan Cameron Signed-off-by: Mark Brown

iio:measurement specialties core: Fix endian sparse warnings.

2015-10-12T17:21:13+00:00

This patch changes various types to the appropriate endian specific versions. Also introduces an additional local variable to avoid a single variable being used for both be and cpu endianness. These aren't bugs as such, but clearing them up does make the code clearer. Warning was: sparse warnings: (new ones prefixed by >>) >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:208:18: sparse: incorrect type in assignment (different base types) drivers/iio/common/ms_sensors/ms_sensors_i2c.c:208:18: expected unsigned short [unsigned] [addressable] [usertype] send_buf drivers/iio/common/ms_sensors/ms_sensors_i2c.c:208:18: got restricted __be16 [usertype] >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:230:18: sparse: incorrect type in assignment (different base types) drivers/iio/common/ms_sensors/ms_sensors_i2c.c:230:18: expected unsigned short [unsigned] [addressable] [usertype] send_buf drivers/iio/common/ms_sensors/ms_sensors_i2c.c:230:18: got restricted __be16 [usertype] drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 Reported-by: kbuild test robot Signed-off-by: Jonathan Cameron

Add meas-spec sensors common part

2015-10-04T13:58:02+00:00

Measurement specialties drivers common part. These functions are used by further drivers in the patchset: TSYS01, TSYS02D, HTU21, MS5637, MS8607 Signed-off-by: Ludovic Tancerel Signed-off-by: Jonathan Cameron

iio: st_sensors: add debugfs register read hook

2015-08-16T09:51:25+00:00

This adds a debugfs hook to read/write registers in the ST sensors using debugfs. Proved to be awesome help when trying to debug why IRQs do not arrive. Signed-off-by: Linus Walleij Acked-by: Denis Ciocca Signed-off-by: Jonathan Cameron