summaryrefslogtreecommitdiffstats
path: root/drivers/iio/light
AgeCommit message (Collapse)AuthorFilesLines
2020-09-29iio: cros_ec: unify hw fifo attributes into the core fileAlexandru Ardelean1-3/+2
The intent here is to minimize the use of iio_buffer_set_attrs(). Since we are planning to add support for multiple IIO buffers per IIO device, the issue has to do with: 1. Accessing 'indio_dev->buffer' directly (as is done with 'iio_buffer_set_attrs(indio_dev->buffer, <attrs>)'). 2. The way that the buffer attributes would get handled or expanded when there are more buffers per IIO device. Current a sysfs kobj_type expands into a 'device' object that expands into an 'iio_dev' object. We will need to change this, so that the sysfs attributes for IIO buffers expand into IIO buffers at some point. Right now, the current IIO framework works fine for the '1 IIO device == 1 IIO buffer' case (that is now). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20200923130339.997902-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-29iio:light:gp2ap002 fix spelling typo in commentsWang Qing1-1/+1
Change the comment typo: "definately" -> "definitely". Signed-off-by: Wang Qing <wangqing@vivo.com> Link: https://lore.kernel.org/r/1600772818-30882-1-git-send-email-wangqing@vivo.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-22Merge tag 'iio-for-5.10b-take2' of ↵Greg Kroah-Hartman2-11/+13
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: Second set of features and cleanups for IIO in 5.10 We have a couple of changes that apply to large sets of drivers, so I have grouped those to keep this short. There are a few late breaking fixes in here that can wait for the merge window. dt yaml conversions ------------------- * adi,ad7768-1 * adi,ad7949 * aspeed,ast2400 * cosmic,10001-adc * dlg,da9150-gpadc * fsl,imx25-gcq * fsl,imx7d-adc * fsl,vf610 * holt,hi8435 * marvell,berlin2-adc * motorola,cpcap-adc * nuvoton,nau7802 * nuvoton,npcm750-adc * nxp,lpc1850-adc * nxp,lpc3220 * sprd,sc2720-adc * st,stmpe-adc * ti,adc12138 * ti,ads1015 * ti,ads7950 * ti,twl4030-madc Features -------- * adxrs290 - Add triggered buffer support and expose data ready signal as a possible trigger. Includes updating bindings. - Add debugfs hooks for register access. * mlx90632 - Add a clear user interface to override the measured ambient temperature. * vl53l0x - Add IRQ support including dt bindings. Cleanups and minor fixes ------------------------ (groups) Replace mlock with local lock: * adf4350 * exynos-adc * fls-imx25-gcq * stm32-dac devm use to simplify probe error handling and remove functions. * adis16201 * adis16203 * adis16209 * adis16240 * adis16136 * adis16260 * adis16400 * adis16460 * adis16480 * adis library - drop unused adis_setup_buffer_and_trigger() of_match_ptr removal and incorrect ACPI binding removal of_match_ptr() rarely makes sense in an IIO driver as space saving is trivial and it breaks ACPI PRP0001 based instantiation. Mostly this series is about removing examples that get copied into new drivers. * ad2s1200 * ad5272 * ad5446 * ad5592r * ad5593r * ad5703 * ak8974 * ak8975 * ams-iaq-core * as3935 * atlas-sensor * ds1803 * hdc100x * htu21 * icp10100 * lmp91000 * pulsedlight * max30102 * max5432 * max5481 * mcp4018 * mcp4131 * mcp4531 * mcp4725 * ms5611 * ms5637 * si7020 * sgp30 * ti-dac082s085 * ti-dac5571 * tmp007 * tsys01 * vz89x * zpa2326 kernel-doc fixes * iio-core * ad7303 * ad7947 * adis16080 * adis16400 * iio_dummy_evgen * sgp30 Fixes for buffer alignment when passed to iio_push_to_buffers_with_timestamp() This is a long running effort. There are a few more drivers to come. * inv_mpu6050 * itg3200 * si1145 * st_lsm6dsx * ti-adc0832 * ti-adc12138 (not driver focused) * MAINTAINERS - Consolidate Analog Device IIO entries whilst removing Beniamin Bia. - Remove Hartmut Knaack as a listed IIO maintainer as he hasn't been active for a long time and people are getting intermitted bounces. * Add __printf() markings to a few functions that were missing them. * drop some rotted documentation from staging. * rework buffer sysfs file creation (precursor to multiple buffer support) (individual drivers) * ad5592r - Fix use of true for IIO_SHARED_BY_TYPE - Tidy up locking and indentation. * ad9467 - Improve error message on chip-id missmatch. - Use more appropriate error value if chip-id not recognised. * adis-library - Simplify burst mode handling. * adxrs290 - Make sure to switch device to standby mode during remove. * as73211 - Increase measurement timeout as seems some devices are slower. * bma180 - Fix use of true fo IIO_SHARED_BY_TYPE * exynos_adc - Update binding to require second interrut with touch screen. - Update binding to not require syscon on S5Pv210 * hmc5843 - Fix use of true for IIO_SHARED_BY_TYPE * inv_mpu6050 - Use regmap_noinc_read() for fifo reading. * palmas_gpadc - Use module_platform_driver() to remove boilerplate. * meson-saradc - style consistency fixes * rockchip_saradc - Allow compile testing with !ARM. * st_lsm6dsx - Changing scaling factor to use IIO_VAL_INT_PLUS_NANO to improve precision. - Fix an issue with unchecked return value. * stm32-adc - Fix a missing return introduced in dev_err_probe() patch earlier in cycle. * sx9310 - Prefer async mode for probe as paticularly slow startup. * vcnl4000 - Add missing interrupt property to dt binding. * tag 'iio-for-5.10b-take2' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (126 commits) dt-bindings: iio: vishay,vcnl4000: add interrupts property iio:imu:inv_mpu6050: Use regmap_noinc_read for fifo reads. iio:imu:inv_mpu6050 Fix dma and ts alignment and data leak issues. iio:adc:ti-adc12138 Fix alignment issue with timestamp iio:adc:ti-adc0832 Fix alignment issue with timestamp iio:imu:st_lsm6dsx Fix alignment and data leak issues iio:light:si1145: Fix timestamp alignment and prevent data leak. iio:gyro:itg3200: Fix timestamp alignment and prevent data leak. iio:imu:st_lsm6dsx: check st_lsm6dsx_shub_read_output return iio: adc: exynos_adc: Replace indio_dev->mlock with own device lock dt-bindings:iio:adc:holt,hi8435 yaml conversion dt-bindings:iio:adc:adi,ad7768-1 yaml conversion dt-bindings:iio:adc:adi,ad7949 yaml conversion dt-bindings:iio:adc:dlg,da9150-gpadc yaml conversion dt-bindings:iio:adc:motorola,cpcap-adc yaml conversion dt-bindings:iio:adc:nxp,lpc3220-adc yaml conversion dt-bindings:iio:adc:nxp,lpc1850-adc yaml conversion dt-bindings:iio:adc:fsl,imx25-gcq yaml conversion dt-bindings:iio:adc:fsl,imx7d-adc yaml conversion dt-bindings:iio:adc:ti,ads1015 yaml conversion ...
2020-09-21iio:light:si1145: Fix timestamp alignment and prevent data leak.Jonathan Cameron1-8/+11
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 24 byte array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable array in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc so no data can leak appart from previous readings. Depending on the enabled channels, the location of the timestamp can be at various aligned offsets through the buffer. As such we any use of a structure to enforce this alignment would incorrectly suggest a single location for the timestamp. Comments adjusted to express this clearly in the code. Fixes: ac45e57f1590 ("iio: light: Add driver for Silabs si1132, si1141/2/3 and si1145/6/7 ambient light, uv index and proximity sensors") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200722155103.979802-9-jic23@kernel.org
2020-09-14Merge 5.9-rc5 into staging-nextGreg Kroah-Hartman3-11/+18
We want the staging/iio changes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-13Merge tag 'staging-5.9-rc5' of ↵Linus Torvalds2-10/+17
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging/IIO driver fixes from Greg KH: "Here are a number of staging and IIO driver fixes for 5.9-rc5. The majority of these are IIO driver fixes, to resolve a timestamp issue that was recently found to affect a bunch of IIO drivers. The other fixes in here are: - small IIO driver fixes - greybus driver fix - counter driver fix (came in through the IIO fixes tree) All of these have been in linux-next for a while with no reported issues" * tag 'staging-5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (23 commits) iio: adc: mcp3422: fix locking on error path iio: adc: mcp3422: fix locking scope iio: adc: meson-saradc: Use the parent device to look up the calib data iio:adc:max1118 Fix alignment of timestamp and data leak issues iio:adc:ina2xx Fix timestamp alignment issue. iio:adc:ti-adc084s021 Fix alignment and data leak issues. iio:adc:ti-adc081c Fix alignment and data leak issues iio:magnetometer:ak8975 Fix alignment and data leak issues. iio:light:ltr501 Fix timestamp alignment issue. iio:light:max44000 Fix timestamp alignment and prevent data leak. iio:chemical:ccs811: Fix timestamp alignment and prevent data leak. iio:proximity:mb1232: Fix timestamp alignment and prevent data leak. iio:accel:mma7455: Fix timestamp alignment and prevent data leak. iio:accel:bmc150-accel: Fix timestamp alignment and prevent data leak. iio:accel:mma8452: Fix timestamp alignment and prevent data leak. iio: accel: kxsd9: Fix alignment of local buffer. iio: adc: rockchip_saradc: select IIO_TRIGGERED_BUFFER iio: adc: ti-ads1015: fix conversion when CONFIG_PM is not set counter: microchip-tcb-capture: check the correct variable iio: cros_ec: Set Gyroscope default frequency to 25Hz ...
2020-09-13iio: light: as73211: Increase measurement timeoutChristian Eggers1-3/+2
We found some sensors which are much slower (20% at room temperature) than nominal. According to the data sheet, up to 27% is possible. Now I add 33% to the nominal time out, hopefully this is enough. Signed-off-by: Christian Eggers <ceggers@arri.de> Link: https://lore.kernel.org/r/20200909154439.10308-1-ceggers@arri.de Fixes: 403e5586b52e ("iio: light: as73211: New driver") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-03iio: light: tsl2772: Simplify with dev_err_probe()Krzysztof Kozlowski1-8/+2
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200829064726.26268-15-krzk@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-03iio: light: isl29018: Simplify with dev_err_probe()Krzysztof Kozlowski1-6/+3
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200829064726.26268-14-krzk@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-03iio: light: as73211: New driverChristian Eggers3-0/+817
Support for AMS AS73211 JENCOLOR(R) Digital XYZ Sensor. This driver has no built-in trigger. In order for making triggered measurements, an external (software) trigger driver like iio-trig-hrtimer or iio-trig-sysfs is required. The sensor supports single and continuous measurement modes. The latter is not used by design as this would require tight timing synchronization between hardware and driver without much benefit. Datasheet: https://ams.com/documents/20143/36005/AS73211_DS000556_3-01.pdf Signed-off-by: Christian Eggers <ceggers@arri.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-08-23treewide: Use fallthrough pseudo-keywordGustavo A. R. Silva1-1/+1
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-22iio:light:ltr501 Fix timestamp alignment issue.Jonathan Cameron1-6/+9
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. Here we use a structure on the stack. The driver already did an explicit memset so no data leak was possible. Forced alignment of ts is not strictly necessary but probably makes the code slightly less fragile. Note there has been some rework in this driver of the years, so no way this will apply cleanly all the way back. Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: <Stable@vger.kernel.org>
2020-08-22iio:light:max44000 Fix timestamp alignment and prevent data leak.Jonathan Cameron1-4/+8
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 16 byte array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv(). This data is allocated with kzalloc so no data can leak appart from previous readings. It is necessary to force the alignment of ts to avoid the padding on x86_32 being different from 64 bit platorms (it alows for 4 bytes aligned 8 byte types. Fixes: 06ad7ea10e2b ("max44000: Initial triggered buffer support") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: <Stable@vger.kernel.org>
2020-07-20iio: light: stk3310: add chip id for STK3311-X variantIcenowy Zheng1-0/+2
The STK3311 chip has a variant called STK3311-X, which has a different chip id of 0x12. Add the chip id to the driver. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: light: us5182d: Fix formatting in kerneldoc function blockLee Jones1-4/+4
Kerneldoc expects attributes/parameters to be in '@*.: ' format. Fixes the following W=1 kernel build warning(s): drivers/iio/light/us5182d.c:457: warning: Function parameter or member 'data' not described in 'us5182d_update_dark_th' drivers/iio/light/us5182d.c:457: warning: Function parameter or member 'index' not described in 'us5182d_update_dark_th' drivers/iio/light/us5182d.c:479: warning: Function parameter or member 'data' not described in 'us5182d_apply_scale' drivers/iio/light/us5182d.c:479: warning: Function parameter or member 'index' not described in 'us5182d_apply_scale' Cc: Adriana Reus <adriana.reus@intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: light: si1145: Demote obvious misuse of kerneldoc to standard comment ↵Lee Jones1-3/+3
blocks No attempt has been made to document any of the demoted functions here Fixes the following W=1 kernel build warning(s): drivers/iio/light/si1145.c:192: warning: Function parameter or member 'data' not described in '__si1145_command_reset' drivers/iio/light/si1145.c:228: warning: Function parameter or member 'data' not described in 'si1145_command' drivers/iio/light/si1145.c:228: warning: Function parameter or member 'cmd' not described in 'si1145_command' drivers/iio/light/si1145.c:1186: warning: Function parameter or member 'trig' not described in 'si1145_trigger_set_state' drivers/iio/light/si1145.c:1186: warning: Function parameter or member 'state' not described in 'si1145_trigger_set_state' Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-20iio: light: cm32181: Fix formatting and docrot issues in cm32181_acpi_get_cpm()Lee Jones1-4/+4
Fixes the following W=1 kernel build warning(s): drivers/iio/light/cm32181.c:107: warning: Function parameter or member 'dev' not described in 'cm32181_acpi_get_cpm' drivers/iio/light/cm32181.c:107: warning: Function parameter or member 'obj_name' not described in 'cm32181_acpi_get_cpm' drivers/iio/light/cm32181.c:107: warning: Function parameter or member 'values' not described in 'cm32181_acpi_get_cpm' drivers/iio/light/cm32181.c:107: warning: Function parameter or member 'count' not described in 'cm32181_acpi_get_cpm' Cc: Kevin Tsai <ktsai@capellamicro.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-07-13Replace HTTP links with HTTPS ones: drivers/iioAlexander A. Klimov2-2/+2
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-20iio: Move attach/detach of the poll func to the coreLars-Peter Clausen7-80/+11
All devices using a triggered buffer need to attach and detach the trigger to the device in order to properly work. Instead of doing this in each and every driver by hand move this into the core. At this point in time, all drivers should have been resolved to attach/detach the poll-function in the same order. This patch removes all explicit calls of iio_triggered_buffer_postenable() & iio_triggered_buffer_predisable() in all drivers, since the core handles now the pollfunc attach/detach. The more peculiar change is for the 'at91-sama5d2_adc' driver, since it's not immediately obvious that removing the hooks doesn't break anything. Eugen was able to test on at91-sama5d2-adc driver, sama5d2-xplained board. All seems to be fine. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Tested-by: Eugen Hristev <eugen.hristev@microchip.com> #for at91-sama5d2-adc Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-14iio: remove left-over parent assignmentsAlexandru Ardelean2-2/+0
These were found by doing some shell magic: ------------ for file in $(git grep -w devm_iio_device_alloc | cut -d: -f1 | sort | uniq) ; do if grep 'parent =' $file | grep -v trig | grep -vq devm_; then echo "$file -> $(grep "parent =" $file)" fi done ----------- The output is bearable [after the semantic patch is applied]. There is a mix of trigger assignments with some iio device parent assignments that are removed via this patch. JC: A few more added via inspection of all parent = statements in drivers/iio. Some of these may just have crossed with this series, others were less obvious to scripting due to some cross file / module boundary calls. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-14iio: light: lm3533-als: use iio_device_set_parent() to assign parentAlexandru Ardelean1-1/+1
This assignment is the more peculiar as it assigns the parent of the platform-device's device (i.e. pdev->dev.parent) as the IIO device's parent. Since the devm_iio_device_alloc() [now] assigns the device argument as the default parent (and since this is the more common case), for cases where the parent needs to be different, the iio_device_set_parent helper should be used. That makes things a bit more obvious about the new behavior of devm_iio_device_alloc() and makes it clearer that iio_device_set_parent() should be used. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-14iio: remove explicit IIO device parent assignmentAlexandru Ardelean46-46/+0
This patch applies the semantic patch: @@ expression I, P, SP; @@ I = devm_iio_device_alloc(P, SP); ... - I->dev.parent = P; It updates 302 files and does 307 deletions. This semantic patch also removes some comments like '/* Establish that the iio_dev is a child of the i2c device */' But this is is only done in case where the block is left empty. The patch does not seem to cover all cases. It looks like in some cases a different variable is used in some cases to assign the parent, but it points to the same reference. In other cases, the block covered by ... may be just too big to be covered by the semantic patch. However, this looks pretty good as well, as it does cover a big bulk of the drivers that should remove the parent assignment. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-14iio: cros_ec: Reapply range at resumeGwendal Grignou1-1/+5
EC does not currently preserve range across sensor reinit. If sensor is powered down at suspend, it will default to the EC default range at resume, not the range set by the host. Save range if modified, and apply at resume. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-14iio: light: stk3310: Constify regmap_configRikard Falkeborn1-1/+1
stk3310_regmap_config is not modified and can be made const to allow the compiler to put it in read-only memory. Before: text data bss dec hex filename 16027 5424 128 21579 544b drivers/iio/light/stk3310.o After: text data bss dec hex filename 16347 5104 128 21579 544b drivers/iio/light/stk3310.o Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-14iio: light: iqs621: remove usage of iio_priv_to_dev()Alexandru Ardelean1-2/+4
We may want to get rid of the iio_priv_to_dev() helper. That's a bit uncertain at this point. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. For this driver, removing iio_priv_to_dev() means keeping a reference on the state struct. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Acked-by: Jeff LaBundy <jeff@labundy.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-06-14iio: light: tsl2563: pass iio device as i2c_client private dataAlexandru Ardelean1-5/+7
We may want to get rid of the iio_priv_to_dev() helper. That's a bit uncertain at this point. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. For this driver, it implies passing the IIO device on the i2c client private data. The implementation of iio_priv() will not be affected by the rework/hiding of iio_priv_to_dev(). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-22iio: light: gp2ap002: Take runtime PM reference on light readJonathan Bakker1-3/+16
The light sensor needs the regulators to be enabled which means the runtime PM needs to be on. This only happened when the proximity part of the chip was enabled. As fallout from this change, only report changes to the prox state in the interrupt handler when it is explicitly enabled. Fixes: 97d642e23037 ("iio: light: Add a driver for Sharp GP2AP002x00F") Signed-off-by: Jonathan Bakker <xc-racer2@live.ca> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-11iio: light: ltr501: Constify structsRikard Falkeborn1-19/+20
Constify some data structs that are never changed. In order to do so, also update a couple of functions that now need to accept pointers to const struct instead of struct. While at it, update a few more functions to accept pointers to const struct instead of pointers. This allows the compiler to put more data in the code segment instead of the data segment, as seen by the output of the file command: Before: text data bss dec hex filename 27080 8144 192 35416 8a58 drivers/iio/light/ltr501.o After: text data bss dec hex filename 27688 7536 192 35416 8a58 drivers/iio/light/ltr501.o Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-11iio: light: cm32181: Fix integartion time typoHans de Goede1-1/+1
Fix integartion time typo and while at it improve the comment with the typo a bit in general. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-11iio: light: cm32181: Add support for parsing CPM0 and CPM1 ACPI tablesHans de Goede1-0/+101
On ACPI based systems the CPLM3218 ACPI device node describing the CM3218[1] sensor typically will have some extra tables with register init values for initializing the sensor and calibration info. This is based on a newer version of cm32181.c, with a copyright of: * Copyright (C) 2014 Capella Microsystems Inc. * Author: Kevin Tsai <ktsai@capellamicro.com> * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2, as published * by the Free Software Foundation. Which is floating around on the net in various places, but the changes from this newer version never made it upstream. This was tested on the following models: Acer Switch 10 SW5-012 (CM32181) Asus T100TA (CM3218), Asus T100CHI (CM3218) and HP X2 10-n000nd (CM32181). Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-10iio: light: cm32181: Make lux_per_bit and lux_per_bit_base_it runtime settingsHans de Goede1-2/+6
Make lux_per_bit and lux_per_bit_base_it settings stored in struct cm32181_chip instead of a hardcoded (defined) values. This is a preparation patch for reading some ACPI tables which specify a device specific lux_per_bit value. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-10iio: light: cm32181: Use units of 1/100000th for calibscale and lux_per_bitHans de Goede1-11/+11
Use units of 1/100000th for calibscale and lux_per_bit. The similar cm3232 driver already uses 1/100000th as unit for calibscale. This allows for higher-accuracy and makes it easier to add support for getting device-specific calibscale and lux_per_bit values from a device's ACPI tables, as the values in the ACPI tables also use 1/100000th units. This units change means that our intermediate values in cm32181_get_lux() may get quite big, change the type of the lux variable to a u64 to deal with this. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-10iio: light: cm32181: Change reg_init to use a bitmap of which registers to initHans de Goede1-8/+6
This is a preparation patch for reading some ACPI tables which give init values for multiple registers. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-10iio: light: cm32181: Handle CM3218 ACPI devices with 2 I2C resourcesHans de Goede1-0/+22
Some ACPI systems list 2 I2C resources for the CM3218 sensor. On these systems the first I2cSerialBus ACPI-resource points to the SMBus Alert Response Address (ARA, 0x0c) and the second I2cSerialBus ACPI-resource points to the actual CM3218 sensor address: Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (SBUF, ResourceTemplate () { I2cSerialBusV2 (0x000C, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2C3", 0x00, ResourceConsumer, , Exclusive, ) I2cSerialBusV2 (0x0048, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2C3", 0x00, ResourceConsumer, , Exclusive, ) Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) { 0x00000033, } }) Return (SBUF) /* \_SB_.I2C3.ALSD._CRS.SBUF */ } Detect this and take the following step to deal with it: 1. When a SMBus Alert capable sensor has an Alert asserted, it will not respond on its actual I2C address. Read a byte from the ARA to clear any pending Alerts. 2. Create a "dummy" client for the actual I2C address and use that client to communicate with the sensor. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-10iio: light: cm32181: Clean up the probe function a bitHans de Goede1-14/+8
3 small cleanups to cm32181_probe(): 1. Do not log an error when we fail to allocate memory (as a general rule drivers do not log errors for this as the kernel will already have complained loudly that it could not alloc the mem). 2. Remove the i2c_set_clientdata() call, we never use i2c_get_clientdata() or dev_get_drvdata() anywhere. 3. Add a dev helper variable and use it in various places instead of &client->dev. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-10iio: light: cm32181: Add support for the CM3218Hans de Goede1-12/+36
Add support for the CM3218 which is an older version of the CM32181. This is based on a newer version of cm32181.c, with a copyright of: * Copyright (C) 2014 Capella Microsystems Inc. * Author: Kevin Tsai <ktsai@capellamicro.com> * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2, as published * by the Free Software Foundation. Which is floating around on the net in various places, but the changes from this newer version never made it upstream. This was tested on an Asus T100TA and an Asus T100CHI, which both come with the CM3218 variant of the light sensor. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-10iio: light: cm32181: Add some extra register definesHans de Goede1-4/+11
These come from a newer version of cm32181.c, which is floating around the net, with a copyright of: * Copyright (C) 2014 Capella Microsystems Inc. * Author: Kevin Tsai <ktsai@capellamicro.com> * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2, as published * by the Free Software Foundation. Note that this removes the bogus CM32181_CMD_ALS_ENABLE define, there is no enable bit, only a disable bit and enabled is the absence of being disabled. This is a preparation patch for adding support for the older CM3218 model of the light sensor. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-10iio: light: cm32181: Add support for ACPI enumerationHans de Goede1-0/+9
Add support for ACPI enumeration, this has been tested on a HP HP Pavilion x2 Detachable 10 (Bay Trail model). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-10iio: light: cm32181: Switch to new style i2c-driver probe functionHans de Goede1-12/+3
Switch to the new style i2c-driver probe_new probe function and drop the unnecessary i2c_device_id table (we do not have any old style board files using this). This is a preparation patch for adding ACPI binding support. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-10iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_triggerAlexandru Ardelean2-28/+8
The main intent here is to get rid of the iio_buffer_set_attrs() helper, or at least rework it's usage a bit. The problem with that helper is that it needs a pointer to the buffer, which makes supporting multiple buffers per IIO device a bit more cumbersome. The hid_sensor_setup_trigger() is pretty much used in the same way: - iio_triggered_buffer_setup() gets called before - then hid_sensor_setup_trigger() and hid_sensor_setup_batch_mode() gets called which may attach some fifo attributes This change merges the 2 together under the hid_sensor_setup_trigger() function. Only the &iio_pollfunc_store_time is passed to all devices, so it's not even required to pass it explicitly outside of the common hid_sensor_setup_trigger() function. Moving the devm_iio_triggered_buffer_setup/cleanup() calls into the common place code can help the rework of the buffer code, since it is in one place. One detail of the change is that there are 2 drivers that use devm_iio_triggered_buffer_setup(). That function gets implicitly replaced with iio_triggered_buffer_setup()/cleanup(), but since all drivers call both hid_sensor_setup_trigger9) & hid_sensor_remove_trigger() trigger, the iio_triggered_buffer_cleanup() piggy backs on the hid_sensor_remove_trigger() call, which should cover the cleanup. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-03iio: vcnl4000: Add buffer support for VCNL4010/20.Mathieu Othacehe2-2/+161
The VCNL4010 and VCNL4020 chips are able to raise interrupts on data ready. Use it to provide triggered buffer support for proximity data. Those two chips also provide ambient light data. However, they are sampled at different rate than proximity data. As this is not handled by the IIO framework for now, and the sample frequencies of ambient light data are very low, do add buffer support for them. Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-03iio: vcnl4000: Add sampling frequency support for VCNL4010/20.Mathieu Othacehe1-1/+117
Add sampling frequency support for proximity data on VCNL4010 and VCNL4020 chips. Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-03iio: vcnl4000: Add event support for VCNL4010/20.Mathieu Othacehe1-62/+392
The VCNL4010 and VCNL4020 chips are able to raise interrupts on proximity threshold events. Add support for threshold rising and falling events for those two chips. Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-03iio: vcnl4000: Factorize data reading and writing.Mathieu Othacehe1-2/+22
Factorize data reading in vcnl4000_measure into a vcnl4000_read_data function. Also add a vcnl4000_write_data function. Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-03iio: vcnl4000: Fix i2c swapped word reading.Mathieu Othacehe1-4/+2
The bytes returned by the i2c reading need to be swapped unconditionally. Otherwise, on be16 platforms, an incorrect value will be returned. Taking the slow path via next merge window as its been around a while and we have a patch set dependent on this which would be held up. Fixes: 62a1efb9f868 ("iio: add vcnl4000 combined ALS and proximity sensor") Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-03iio: light: zopt2201: Use get_unaligned_le24()Andy Shevchenko1-1/+3
This makes the driver code slightly easier to read. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-03iio: light: si1133: Use get_unaligned_be24()Andy Shevchenko1-12/+6
This makes the driver code slightly easier to read. Cc: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-04-25iio: light: vl6180: add include of mod_devicetable.h and drop of_match_ptrJonathan Cameron1-1/+2
Enables probing via ACPI PRP0001 route and removes an example of an approach we no longer want people to copy. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
2020-04-25iio: light: st_uvis25: Add mod_devicetable.h and drop of_match_ptrJonathan Cameron2-2/+4
Enables probing via ACPI PRP0001 and removes an example that we don't want people to cut and paste into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
2020-04-25iio: light: opt3001: Add mod_devicetable.h and drop use of of_match_ptrJonathan Cameron1-1/+2
Enables probing via ACPI PRP0001 but mostly about removing examples that might be copied to new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-06 13:29:09 +0000