kernel/linux.git/drivers/iio/common, branch linux-4.20.y

iio: change strncpy+truncation to strlcpy

2018-07-15T10:38:06+00:00

Generated by scripts/coccinelle/misc/strncpy_truncation.cocci Signed-off-by: Dominique Martinet Signed-off-by: Jonathan Cameron

Merge tag 'staging-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging

2018-06-09T17:32:39+00:00

Pull staging/IIO updates from Greg KH: "Here is the big staging and IIO driver update for 4.18-rc1. It was delayed as I wanted to make sure the final driver deletions did not cause any major merge issues, and all now looks good. There are a lot of patches here, just over 1000. The diffstat summary shows the major changes here: 1007 files changed, 16828 insertions(+), 227770 deletions(-) Because of this, we might be close to shrinking the overall kernel source code size for two releases in a row. There was loads of work in this release cycle, primarily: - tons of ks7010 driver cleanups - lots of mt7621 driver fixes and cleanups - most driver cleanups - wilc1000 fixes and cleanups - lots and lots of IIO driver cleanups and new additions - debugfs cleanups for all staging drivers - lots of other staging driver cleanups and fixes, the shortlog has the full details. but the big user-visable things here are the removal of 3 chunks of code: - ncpfs and ipx were removed on schedule, no one has cared about this code since it moved to staging last year, and if it needs to come back, it can be reverted. - lustre file system is removed. I've ranted at the lustre developers about once a year for the past 5 years, with no real forward progress at all to clean things up and get the code into the "real" part of the kernel. Given that the lustre developers continue to work on an external tree and try to port those changes to the in-kernel tree every once in a while, this whole thing really really is not working out at all. So I'm deleting it so that the developers can spend the time working in their out-of-tree location and get things cleaned up properly to get merged into the tree correctly at a later date. Because of these file removals, you will have merge issues on some of these files (2 in the ipx code, 1 in the ncpfs code, and 1 in the atomisp driver). Just delete those files, it's a simple merge :) All of this has been in linux-next for a while with no reported problems" * tag 'staging-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (1011 commits) staging: ipx: delete it from the tree ncpfs: remove uapi .h files ncpfs: remove Documentation ncpfs: remove compat functionality staging: ncpfs: delete it staging: lustre: delete the filesystem from the tree. staging: vc04_services: no need to save the log debufs dentries staging: vc04_services: vchiq_debugfs_log_entry can be a void * staging: vc04_services: remove struct vchiq_debugfs_info staging: vc04_services: move client dbg directory into static variable staging: vc04_services: remove odd vchiq_debugfs_top() wrapper staging: vc04_services: no need to check debugfs return values staging: mt7621-gpio: reorder includes alphabetically staging: mt7621-gpio: change gc_map to don't use pointers staging: mt7621-gpio: use GPIOF_DIR_OUT and GPIOF_DIR_IN macros instead of custom values staging: mt7621-gpio: change 'to_mediatek_gpio' to make just a one line return staging: mt7621-gpio: dt-bindings: update documentation for #interrupt-cells property staging: mt7621-gpio: update #interrupt-cells for the gpio node staging: mt7621-gpio: dt-bindings: complete documentation for the gpio staging: mt7621-dts: add missing properties to gpio node ...

Merge tag 'iio-fixes-for-4.17a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus

2018-05-09T15:08:29+00:00

Jonathan writes: First round of IIO fixes for the 4.17 cycle. * core - fix up some issues with overflow etc around wrong types for some fo the kfifo handling functions. Seems unlikely this would be triggered in reality but the fixes are simple so let's tidy them up. Second patch deals with checking the userspace value passed for length for potential overflow. * ad7793 - Catch up with changes to the ad_sigma_delta core and use read_raw / write_raw iwth IIO_CHAN_INFO_SAMP_FEW to handle sampling frequency control. * at91-sama5d2 - Channel config for differential channels was completely broken. - Missing Kconfig dependency for buffer support. * hid-sensor - Fix an issue with powering up after resume due to wrong reference counting. * stm32-dfsdm - Fix an issue with second writes of the oversampling settings failing. - Fix an issue with the sample rate being set to half of requested value when particular clock source is used.

iio: common: hid-sensors: simplify getting .drvdata

2018-04-28T15:17:59+00:00

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang Signed-off-by: Jonathan Cameron

iio: common: cros_ec_sensors: simplify getting .drvdata

2018-04-28T15:17:59+00:00

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang Signed-off-by: Jonathan Cameron

iio: hid-sensor-trigger: Fix sometimes not powering up the sensor after resume

2018-04-21T14:52:35+00:00

hid_sensor_set_power_work() powers the sensors back up after a resume based on the user_requested_state atomic_t. But hid_sensor_power_state() treats this as a boolean flag, leading to the following problematic scenario: 1) Some app starts using the iio-sensor in buffered / triggered mode, hid_sensor_data_rdy_trigger_set_state(true) gets called, setting user_requested_state to 1. 2) Something directly accesses a _raw value through sysfs, leading to a call to hid_sensor_power_state(true) followed by hid_sensor_power_state(false) call, this sets user_requested_state to 1 followed by setting it to 0. 3) Suspend/resume the machine, hid_sensor_set_power_work() now does NOT power the sensor back up because user_requested_state (wrongly) is 0. Which stops the app using the sensor in buffered mode from receiving any new values. This commit changes user_requested_state to a counter tracking how many times hid_sensor_power_state(true) was called instead, fixing this. Cc: Bastien Nocera Cc: Srinivas Pandruvada Signed-off-by: Hans de Goede Acked-by: Srinivas Pandruvada Cc: Signed-off-by: Jonathan Cameron

iio: cros_ec: Move cros_ec_sensors_core.h in /include

2018-03-17T19:59:20+00:00

Similar to other common iio frameworks, move cros_ec_sensors_core.h from drivers/iio/common/cros_ec_sensors/ to include/linux/iio/common. Signed-off-by: Gwendal Grignou Signed-off-by: Jonathan Cameron

iio: cros_ec: Relax sampling frequency before suspending

2018-03-03T15:02:58+00:00

If an application set a tight sampling frequency, given the interrupt use is a wakeup source, suspend will not happen: the kernel will receive a wake up interrupt and will cancel the suspend process. Given cros_ec sensors type is non wake up, this patch adds prepare and complete callbacks to set 1s sampling period just before suspend. This ensures the sensor hub will not be a source of interrupt during the suspend process. Signed-off-by: Gwendal Grignou Signed-off-by: Enric Balletbo i Serra Acked-by: Jonathan Cameron Signed-off-by: Jonathan Cameron

iio: common: ssp_sensors: account for const type of of_device_id.data

2018-01-08T15:03:43+00:00

This driver creates a number of const structures that it stores in the data field of an of_device_id array. Add const to the declaration of the location that receives a value from the data field to ensure that the compiler will continue to check that the value is not modified and remove the const-dropping cast on the access to the data field. Done using Coccinelle. Signed-off-by: Julia Lawall Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: common: ssp_sensors: use ktime_get_real_ns() timestamps

2018-01-08T15:03:41+00:00

getnstimeofday() suffers from the overflow in y2038 on 32-bit architectures and requires a conversion into the nanosecond format that we want here. This changes ssp_parse_dataframe() to use ktime_get_real_ns() directly, which does not have that problem. An open question is what time base should be used here. Normally timestamps should use ktime_get_ns() or ktime_get_boot_ns() to read monotonic time instead of "real" time, which suffers from time jumps due to settimeofday() calls or leap seconds. Signed-off-by: Arnd Bergmann Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman