summaryrefslogtreecommitdiffstats
path: root/drivers/iio
AgeCommit message (Collapse)AuthorFilesLines
2016-10-05Merge tag 'staging-4.9-rc1' of ↵Linus Torvalds69-324/+8182
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging and IIO updates from Greg KH: "Here is the big staging and IIO driver pull request for 4.9-rc1. There are a lot of patches in here, the majority due to the drivers/staging/greybus/ subsystem being merged in with full development history that went back a few years, in order to preserve the work that those developers did over time. Lots and lots of tiny cleanups happened in the tree as well, due to the Outreachy application process and lots of other developers showing up for the first time to clean code up. Along with those changes, we deleted a wireless driver, and added a raspberrypi driver (currently marked broken), and lots of new iio drivers. Overall the tree still shrunk with more lines removed than added, about 10 thousand lines removed in total. Full details are in the very long shortlog below. All of this has been in the linux-next tree with no issues. There will be some merge problems with other subsystem trees, but those are all minor problems and shouldn't be hard to work out when they happen (MAINTAINERS and some lustre build problems with the IB tree)" And furter from me asking for clarification about greybus: "Right now there is a phone from Motorola shipping with this code (a slightly older version, but the same tree), so even though Ara is not alive in the same form, the functionality is happening. We are working with the developers of that phone to merge the newer stuff in with their fork so they can use the upstream version in future versions of their phone product line. Toshiba has at least one chip shipping in their catalog that needs/uses this protocol over a Unipro link, and rumor has it that there might be more in the future. There are also other users of the greybus protocols, there is a talk next week at ELC that shows how it is being used across a network connection to control a device, and previous ELC talks have showed the protocol stack being used over USB to drive embedded Linux boards. I've also talked to some people who are starting to work to add a host controller driver to control arduinos as the greybus PHY protocols are very useful to control a serial/i2c/spio/whatever device across a random physical link, as it is a way to have a self-describing device be attached to a host without needing manual configuration. So yes, people are using it, and there is still the chance that it will show up in a phone/laptop/tablet/whatever from Google in the future as well, the tech isn't dead, even if the original large phone project happens to be" * tag 'staging-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (3703 commits) Staging: fbtft: Fix bug in fbtft-core staging: rtl8188eu: fix double unlock error in rtw_resume_process() staging:r8188eu: remove GEN_MLME_EXT_HANDLER macro staging:r8188eu: remove GEN_DRV_CMD_HANDLER macro staging:r8188eu: remove GEN_EVT_CODE macro staging:r8188eu: remove GEN_CMD_CODE macro staging:r8188eu: remove pkt_newalloc member of the recv_buf structure staging:r8188eu: remove rtw_handle_dualmac declaration staging:r8188eu: remove (RGTRY|BSSID)_(OFT|SZ) macros staging:r8188eu: change rtl8188e_process_phy_info function argument type Staging: fsl-mc: Remove blank lines Staging: fsl-mc: Fix unaligned * in block comments Staging: comedi: Align the * in block comments Staging : ks7010 : Fix block comments warninig Staging: vt6655: Remove explicit NULL comparison using Coccinelle staging: rtl8188eu: core: rtw_xmit: Use macros instead of constants staging: rtl8188eu: core: rtw_xmit: Move constant of the right side staging: dgnc: Fix lines longer than 80 characters Staging: dgnc: constify attribute_group structures Staging: most: hdm-dim2: constify attribute_group structures ...
2016-10-03Merge tag 'char-misc-4.9-rc1' of ↵Linus Torvalds1-2/+0
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver updates from Greg KH: "Here's the "big" char and misc driver update for 4.9-rc1. Lots of little things here, all over the driver tree for subsystems that flow through me. Nothing major that I can discern, full details are in the shortlog. All have been in the linux-next tree with no reported issues" * tag 'char-misc-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (144 commits) drivers/misc/hpilo: Changes to support new security states in iLO5 FW at25: fix debug and error messaging misc/genwqe: ensure zero initialization vme: fake: remove unexpected unlock in fake_master_set() vme: fake: mark symbols static where possible spmi: pmic-arb: Return an error code if sanity check fails Drivers: hv: get rid of id in struct vmbus_channel Drivers: hv: make VMBus bus ids persistent mcb: Add a dma_device to mcb_device mcb: Enable PCI bus mastering by default mei: stop the stall timer worker if not needed clk: probe common clock drivers earlier vme: fake: fix build for 64-bit dma_addr_t ttyprintk: Neaten and simplify printing mei: me: add kaby point device ids coresight: tmc: mark symbols static where possible coresight: perf: deal with error condition properly Drivers: hv: hv_util: Avoid dynamic allocation in time synch fpga manager: Add hardware dependency to Zynq driver Drivers: hv: utils: Support TimeSync version 4.0 protocol samples. ...
2016-09-18iio: light: Add driver for Silabs si1132, si1141/2/3 and si1145/6/7 ambient ↵Peter Meerwald-Stadler3-0/+1418
light, uv index and proximity sensors The si114x supports x=1,2,3 IR LEDs for proximity sensing together with visible and IR ambient light sensing (ALS). Newer parts (si1132, si1145/6/7) can measure UV light and compute an UV index This was tested on si1143 and si1145 Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio:pressure: initial zpa2326 barometer supportGregor Boirie6-0/+2051
Introduce driver for Murata ZPA2326 pressure and temperature sensor: http://www.murata.com/en-us/products/productdetail?partno=ZPA2326-0311A-R Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: Add driver for the mCube MC3230 3-axis accelerometerHans de Goede3-0/+222
Add an IIO driver for the mCube MC3230 3-axis accelerometer. A datasheet for the mCube MC3230 can be found here: http://www.mcubemems.com/wp-content/uploads/2014/10/MC3230_2-Datasheet-APS-048-0007v1.6.pdf Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: mma7660: fix missing MODULE_DEVICE_TABLE(i2c)Hans de Goede1-0/+1
Add missing MODULE_DEVICE_TABLE(i2c) this fixes autoloading on devicetree using systems. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: common: ssp_sensors: gyro: constify iio_info structuresJulia Lawall1-1/+1
Check for iio_info structures that are only stored in the info field of a iio_dev structure. This field is declared const, so iio_info structures that have this property can be declared as const also. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r disable optional_qualifier@ identifier i; position p; @@ static struct iio_info i@p = { ... }; @ok@ identifier r.i; struct iio_dev e; position p; @@ e.info = &i@p; @bad@ position p != {r.p,ok.p}; identifier r.i; struct iio_info e; @@ e@i@p @depends on !bad disable optional_qualifier@ identifier r.i; @@ static +const struct iio_info i = { ... }; // </smpl> The result of size on this file before the change is: text data bss dec hex filename 1245 344 0 1589 635 drivers/iio/gyro/ssp_gyro_sensor.o and after the change it is: text data bss dec hex filename 1397 192 0 1589 635 drivers/iio/gyro/ssp_gyro_sensor.o Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: adc: men_z188_adc: constify iio_info structuresJulia Lawall1-1/+1
Check for iio_info structures that are only stored in the info field of a iio_dev structure. This field is declared const, so iio_info structures that have this property can be declared as const also. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r disable optional_qualifier@ identifier i; position p; @@ static struct iio_info i@p = { ... }; @ok@ identifier r.i; struct iio_dev e; position p; @@ e.info = &i@p; @bad@ position p != {r.p,ok.p}; identifier r.i; struct iio_info e; @@ e@i@p @depends on !bad disable optional_qualifier@ identifier r.i; @@ static +const struct iio_info i = { ... }; // </smpl> The result of size on this file before the change is: text data bss dec hex filename 1529 312 0 1841 731 drivers/iio/adc/men_z188_adc.o and after the change it is: text data bss dec hex filename 1689 168 0 1857 741 drivers/iio/adc/men_z188_adc.o Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: common: ssp_sensors: accel: constify iio_info structuresJulia Lawall1-1/+1
Check for iio_info structures that are only stored in the info field of a iio_dev structure. This field is declared const, so iio_info structures that have this property can be declared as const also. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r disable optional_qualifier@ identifier i; position p; @@ static struct iio_info i@p = { ... }; @ok@ identifier r.i; struct iio_dev e; position p; @@ e.info = &i@p; @bad@ position p != {r.p,ok.p}; identifier r.i; struct iio_info e; @@ e@i@p @depends on !bad disable optional_qualifier@ identifier r.i; @@ static +const struct iio_info i = { ... }; // </smpl> The result of size on this file before the change is: text data bss dec hex filename 1265 344 0 1609 649 drivers/iio/accel/ssp_accel_sensor.o and after the change it is: text data bss dec hex filename 1425 192 0 1617 651 drivers/iio/accel/ssp_accel_sensor.o Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Support reading a mounting matrixLinus Walleij1-0/+24
This adds support for the mounting matrix to the KXSD9 driver. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Deploy system and runtime PMLinus Walleij4-2/+94
This deploys runtime and system PM in the KXSD9 driver: - Use the force_runtime_suspend/resume callbacks as system PM operations. - Add buffer prepare/unprepare callbacks to grab the runtime PM while we're using buffered reads and put get/put_autosuspend in these. - Insert get/put_autosuspend calls anywhere the IO is used from the raw read/write callbacks. - Move the fullscale setting to be cached in the state container so we can restore it properly when coming back from system/runtime suspend. - Set the autosuspend delay to two orders of magnitude that of the sensor start-up time (20ms) so we will autosuspend after 2s. - Register the callbacks in both the SPI and I2C subdrivers. Tested with the I2C KXSD9 on the Qualcomm APQ8060 Dragonboard. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Replace "parent" with "dev"Linus Walleij2-12/+12
What is passed to the .probe() and .remove() functions is technically the parent of the created IIO device but it becomes a big confusion for the head to have it named like this since it is usually clear from context the "dev" refers to the physical device, and when next adding PM callbacks a clean "struct device *dev" pointer is passed to these and that makes it even more confused. Rename "parent" to "dev" like in most other drivers. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Fetch and handle regulatorsLinus Walleij1-3/+85
This adds supply regulator handling for the VDD and IOVDD inputs on the KXSD9 component, makes sure to bring the regulators online during probe and disable them on remove or the errorpath. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Deploy proper register bit definesLinus Walleij1-9/+27
There are some hardcoded register values etc in the code, define proper bitfield definitions, and use them when getting and setting the scale. Optimize a read/modify/write to use regmap_update_bits() at the same time. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Add triggered buffer handlingLinus Walleij2-6/+78
As is custom with all modern sensors, add a clever burst mode that will just stream out values from the sensor and provide it to userspace to do the proper offsetting and scaling. This is the result when tested with an HRTimer trigger: $ generic_buffer -a -c 10 -n kxsd9 -t foo /sys/bus/iio/devices/iio:device1 foo 0.371318 0.718680 9.869872 1795.000000 97545896129 -0.586922 0.179670 9.378775 2398.000000 97555864721 -0.299450 0.179670 10.348992 2672.000000 97565874055 0.371318 0.335384 11.103606 2816.000000 97575883240 0.179670 0.574944 10.540640 2847.000000 97585862351 0.335384 0.754614 9.953718 2840.000000 97595872425 0.179670 0.754614 10.732288 2879.000000 97605882351 0.000000 0.754614 10.348992 2872.000000 97615891832 -0.730658 0.574944 9.570422 2831.000000 97625871536 0.000000 1.137910 10.732288 2872.000000 97635881610 Columns shown are x, y, z acceleration, so a positive acceleration of ~9.81 (shaky due to bad calibration) along the z axis. The fourth column is the AUX IN which is floating on this system, it seems to float up to the 2.85V VDD voltage. To be able to cleanup the triggered buffer, we need to add .remove() callbacks to the I2C and SPI subdrivers and call back into an exported .remove() callback in the core. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Fix up offset and scalingLinus Walleij1-17/+18
This fixes several errors in the offset and scaling of the raw values from the KXSD9 sensor: - The code did not convert the big endian value from the sensor into the endianness of the host CPU. Fix this with be16_to_cpu() on the raw obtained value. - The code did not regard the fact that only the upper 12 bits of the accelerometer values are valid. Shift these down four bits to yield the real raw value. - Further the sensor provides 2048 at zero g. This means that an offset of 2048 must be subtracted from the raw value before scaling. This was not taken into account by the driver, yielding a weird value. Fix this by providing this offset in sysfs. To house the scaling code better, the value reading code was factored into the raw reading function. This proper scaling and offseting is necessary to get proper values out of triggered buffer by offsetting, shifting and scaling them. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Drop the buffer lockLinus Walleij1-14/+4
The RX/TX buffers are gone so drop the lock (it should have been in the transport struct anyway). Tested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Add I2C transportLinus Walleij3-1/+75
This adds I2C regmap transport for the KXSD9 driver. Tested on the KXSD9 sensor on the APQ8060 Dragonboard. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Convert to use regmap for transportLinus Walleij4-99/+43
This converts the KXSD9 driver to drop the custom transport mechanism and just use regmap like everything else. Tested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Do away with the write2 helperLinus Walleij3-14/+2
This is just a masquerading register write function, so use the register write function instead. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Split out SPI transportLinus Walleij5-127/+173
This moves the KXSD9 SPI transport out to its own file and Kconfig entry, so that we will be able to add another transport method. We export the common probe and add a local header file for the functionality shared between the main driver and the transport driver. We make the SPI transport the default for the driver if SPI is available and the KXSD9 driver was selected, so the oldconfig upgrade path will be clear. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: split out a common remove() functionLinus Walleij1-10/+14
This makes it possible to later split the transport mechanism using a generic probe() and a generic remove(). Use dev_set_drvdata() and dev_get_drvdata() as a paired accessor to operate on the abstract struct device * regardless of the transport mechanism in use. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-18iio: accel: kxsd9: Split out transport mechanismLinus Walleij1-52/+123
Split off a transport mechanism struct that will deal with the SPI traffic in preparation for adding I2C support. Tested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-14Merge tag 'iio-for-4.9b' of ↵Greg Kroah-Hartman28-133/+1497
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: Second set of iio new device support, features and cleanups for the 4.9 cycle. New device support * ad8801 dac - new driver supporting ad8801 and ad8803 DACs. * adc12138 - new driver supporting TI adc12130/adc12132 and adc12138 ADCs. * ltc2485 adc - new driver * mxc6255 - add support for the mxc6225 part name and fixup the ID check so it works. * vz89x VOC sensor - add support for the vz89te part which drops the voc_short channel and adds CRCs compared to other supported parts. New features * core - immutable triggers. These effectively grant exclusive control over a trigger. The typical usecase is a device representing an analog part (perhaps a MUX) that needs to control the sampling of a downstream ADC. - resource managed trigger registration and triggered_buffer_init. - iio_push_event now protected against case of the event interface registration not having yet occured. Only matters if an interrupt can occur during this window - might happen on shared interrupt lines. - helper to let a driver query if the trigger it is using is provided by itself (using the convention of both device and trigger having the same parent). * tools - iio-utils. Used channel modifier scaling in preference to generic scaling when both exist. * at91-adc - Add support for touchscreen switches closure time needed by some newer parts. * stx104 - support the ADC channels on this ADC/DAC board. As these are the primary feature of the board also move the driver to the iio/adc directory. * sx9500 - device tree bindings. Cleanups / Fixes * ad5755 - fix an off-by-one on devnr limit check (introduced earlier this cycle) * ad7266 - drop NULL check on devm_regulator_get_optional as it can't return NULL. * ak8974 - avoid an unused functional warning due to rework in PM core code. - remove .owner field setting as done by i2c_core. * ina2xx - clear out a left over debug field from chip global data. * hid-sensors - avoid an unused functional warning due to rework in PM core code. * maxim-thermocouple - fix non static symbol warnings. * ms5611 - fetch and enable regulators unconditionally when they aren't optional. * sca3000 - whitespace cleanup. * st_sensors - fetch and enable regulators unconditionally rather than having them supported as optional regulators (missunderstanding on my part amongst others a while back) - followup to previous patch fixes error checking on the regulators. - mark symbols static where possible. - use the 'is it my trigger' help function. This prevents the odd case of another device triggering from the st-sensors trigger whilst the st-sensors trigger is itself not using it but rather using say an hrtimer. * ti-ads1015 - add missing of_node_put. * vz89x - rework to all support of new devices. - prevent reading of a corrupted buffer. - fixup a return value of 0/1 in a bool returning function. Address updates - Vlad Dogaru email address change.
2016-09-12iio: accel: mxc6255: Fix chip-id checkHans de Goede1-6/+1
The initial commit adding support for the mxc6225 assumed the mxc6225 has a chip-id of 0xe5 based on testing on a single Allwinner A23 tablet with a mxc6225. Testing on a bunch of other Allwinner tablets have shown that the chip-id for the mxc6225 is not constant. A datasheet for the MXC6255 which I've found online says that bits 7 and 6 of the chip-id register are undefined (for the mxc6255), testing on 5 different tablets with a mxc6225 has found the following ids: 0x25, 0x45, 0x65, 0x85, 0xe5. So it seems that for the mxc6225 bits 7, 6 and 5 of the chip-id register are undefined. This commit adjusts the chip-id check so that the mxc6255 driver properly recognizes the mxc6225 in all these tablets. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-12Merge 4.8-rc6 into staging-nextGreg Kroah-Hartman5-7/+18
We need the IIO changes in here for future patches to build on. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-10iio: st_sensors: use the helper functionLinus Walleij1-1/+1
The ST sensors can be used as a trigger for its own triggered buffer but it is also possible to use an external trigger: a HRTimer or even a different sensor (!) as trigger. In that case we should not pick the timestamp from our own interrupt top half even if it is active. This could practically happen if some other sensor is using the ST sensor as trigger but the ST sensor itself is using e.g. an HRTimer as trigger. So the trigger is on, but not used by us. We used to assume that whenever the hardware interrupt is turned on, we are using it for our own trigger, but this is an oversimplification. Handle this logically by using the iio_trigger_using_own() helper. Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Cc: Crestez Dan Leonard <leonard.crestez@intel.com> Cc: Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-10iio: trigger: helpers to determine own triggerLinus Walleij1-0/+16
This adds a helper function to the IIO trigger framework: iio_trigger_using_own(): for an IIO device, this tells whether the device is using itself as a trigger. This is true if the indio device: (A) supplies a trigger and (B) has assigned its own buffer poll function to use this trigger. This helper function is good when constructing triggered, buffered drivers that can either use its own hardware *OR* an external trigger such as a HRTimer or even the trigger from a totally different sensor. Under such circumstances it is important to know for example if the timestamp from the same trigger hardware should be used when populating the buffer: if iio_trigger_using_own() is true, we can use this timestamp, else we need to pick a unique timestamp directly in the trigger handler. For this to work of course IIO devices registering hardware triggers must follow the convention to set the parent device properly, as as well as setting the parent of the IIO device itself. When a new poll function is attached, we check if the parent device of the IIO of the poll function is the same as the parent device of the trigger and in that case we conclude that the hardware is using itself as trigger. Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Cc: Crestez Dan Leonard <leonard.crestez@intel.com> Cc: Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-10iio: iio_push_event(): Don't crash if the event interface is not registeredLars-Peter Clausen1-0/+8
iio_push_event() operates on a struct iio_dev. This struct can be allocated using iio_device_alloc() which returns a valid struct iio_dev pointer. But iio_push_event() is not safe to use on such a iio_dev until iio_device_register() for the same device has successfully completed. This restriction is not documented anywhere and most drivers are written with the assumption that this restriction does not exist. The basic pattern that is followed by all drivers looks like the following: irqreturn_t event_callback(int irq, void *devid) { struct iio_dev *indio_dev = devid; ... iio_push_event(indio_dev, ...); return IRQ_HANDLED; } int driver_probe(struct device *dev) { struct iio_dev *indio_dev; indio_dev = iio_device_alloc(...); request_irq(event_irq, event_callback, ..., indio_dev); return iio_device_register(indio_dev); } And while it is unlikely that the IRQ fires before iio_device_register() completes (e.g. because the IRQ is disabled in the device) it is not impossible and might be triggered by glitches on the signal line or incorrect hardware configuration. To avoid undefined behaviour in such a case extend iio_push_event() to check if the event has been registered and discard generated events if it has not. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-09Merge tag 'iio-fixes-for-4.8b' of ↵Greg Kroah-Hartman5-7/+18
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: Second set of IIO fixes for the 4.8 cycle. We have a big rework of the kxsd9 driver queued up behind the fix below and a fix for a recent fix that was marked for stable. Hence this fix series is perhaps a little more urgent than average for IIO. * core - a fix for a fix in the last set. The recent fix for blocking ops when ! task running left a path (unlikely one) in which the function return value was not set - so initialise it to 0. - The IIO_TYPE_FRACTIONAL code previously didn't cope with negative fractions. Turned out a fix for this was in Analog's tree but hadn't made it upstream. * bmc150 - reset chip at init time. At least one board out there ends up coming up in an unstable state due to noise during power up. The reset does no harm on other boards. * kxsd9 - Fix a bug in the reported scaling due to failing to set the integer part to 0. * hid-sensors-pressure - Output was in the wrong units to comply with the IIO ABI. * tools - iio_generic_buffer: Fix the trigger-less mode by ensuring we don't fault out for having no trigger when we explicitly said we didn't want to have one.
2016-09-05iio:core: fix IIO_VAL_FRACTIONAL sign handlingGregor Boirie1-3/+2
7985e7c100 ("iio: Introduce a new fractional value type") introduced a new IIO_VAL_FRACTIONAL value type meant to represent rational type numbers expressed by a numerator and denominator combination. Formating of IIO_VAL_FRACTIONAL values relies upon do_div() usage. This fails handling negative values properly since parameters are reevaluated as unsigned values. Fix this by using div_s64_rem() instead. Computed integer part will carry properly signed value. Formatted fractional part will always be positive. Fixes: 7985e7c100 ("iio: Introduce a new fractional value type") Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-05iio: accel: mxc6255 add support for the mxc6225Hans de Goede1-1/+8
The mxc6225 is fully compatible with the existing mxc6255 driver, add support for it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-05iio: adc: at91: Add support for Touchscreen Switches Closure TimeNicolas Ferre1-0/+13
On newer components compatible with the at91sam9x5, the Touchscreen Switches Closure Time or TSSCTIM value of the Touchscreen Mode Register is not filled at all. On some hardware, having no time indicated for it may lead to incoherent values and jitter. We fix this time to 10us as it is usually difficult to retrieve impedance values from LCD manufacturers. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-05iio: devm_regulator_get_optional never returns NULLCrt Mori2-4/+4
This patch is inspired by a comment of Jonathan Cameron on patch of Linus Walleij commit aeb55fff3891834e07a3144159a7298a19696af8 ("iio: st_sensors: fetch and enable regulators unconditionally"). Because changes made in this patch are actually reference generators they should be using devm_regulator_get_optional, but if they do not explicitly set the reference to NULL they should not be using IS_ERR_OR_NULL, but simple IS_ERR check. Suggested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Crt Mori <cmo@melexis.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-05iio: fetch and enable regulators unconditionallyCrt Mori1-4/+2
This patch is inspired by a comment of Jonathan Cameron on patch of Linus Walleij commit aeb55fff3891834e07a3144159a7298a19696af8 ("iio: st_sensors: fetch and enable regulators unconditionally"). The explanation for this change is same as in that patch: "Supplies are *not* optional (optional means that the supply is optional in the electrical sense, not the software sense) so we need to get the and enable them at all times. If the device tree or board file does not define suitable regulators for the component, it will be substituted by a dummy regulator, or, if regulators are disabled altogether, by stubs. There is no need to use the IS_ERR_OR_NULL() check that is considered harmful. Reported-by: Linus Wallerij <linus.walleij@linaro.org> Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Crt Mori <cmo@melexis.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-05iio: ensure ret is initialized to zero before entering do loopColin Ian King1-2/+2
A recent fix to iio_buffer_read_first_n_outer removed ret from being set by a return from wait_event_interruptible and also added a continue in a loop which causes the variable ret to not be set when it reaches the end of the loop. Fix this by initializing ret to zero. Also remove extraneous white space at the end of the loop. Fixes: fcf68f3c0bb2a5 ("fix sched WARNING "do not call blocking ops when !TASK_RUNNING") Signed-off-by: Colin Ian King <colin.king@canonical.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-05Merge 4.8-rc5 into staging-nextGreg Kroah-Hartman18-51/+119
We want the staging fixes in here as well to handle merge issues. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-05Merge 4.8-rc5 into char-misc-nextGreg Kroah-Hartman18-51/+119
We want the fixes in here for merging and testing. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-04iio: add resource managed triggered buffer init helpersGregor Boirie2-1/+44
Add resource managed devm_iio_triggered_buffer_setup() and devm_iio_triggered_buffer_cleanup() to automatically clean up triggered buffers setup by IIO drivers, thus leading to simplified IIO drivers code. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-04iio:trigger: add resource managed (un)registerGregor Boirie1-0/+59
Add resource managed devm_iio_trigger_register() and devm_iio_triger_unregister() to automatically clean up registered triggers allocated by IIO drivers, thus leading to simplified IIO drivers code. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-03Merge tag 'char-misc-4.8-rc5' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "Here are a number of small driver fixes for 4.8-rc5. The largest thing here is deleting an obsolete driver, drivers/misc/bh1780gli.c, as the functionality of it was replaced by an iio driver a while ago. The other fixes are things that have been reported, or reverts of broken stuff (the binder change). All of these changes have been in linux-next for a while with no reported issues" * tag 'char-misc-4.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: thunderbolt: Don't declare Falcon Ridge unsupported thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller. thunderbolt: Fix resume quirk for Falcon Ridge 4C. lkdtm: Mark lkdtm_rodata_do_nothing() notrace mei: me: disable driver on SPT SPS firmware Revert "android: binder: fix dangling pointer comparison" drivers/iio/light/Kconfig: SENSORS_BH1780 cleanup android: binder: fix dangling pointer comparison misc: delete bh1780 driver
2016-09-03iio: accel: kxsd9: Fix scaling bugLinus Walleij1-0/+1
All the scaling of the KXSD9 involves multiplication with a fraction number < 1. However the scaling value returned from IIO_INFO_SCALE was unpredictable as only the micros of the value was assigned, and not the integer part, resulting in scaling like this: $cat in_accel_scale -1057462640.011978 Fix this by assigning zero to the integer part. Cc: stable@vger.kernel.org Tested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-03iio: chemical: vz89x: fix boolreturn.cocci warningskbuild test robot1-1/+1
drivers/iio/chemical/vz89x.c:119:9-10: WARNING: return of 0/1 in function 'vz89x_measurement_is_valid' with return type bool Return statements in functions returning bool should use true/false instead of 1/0. Generated by: scripts/coccinelle/misc/boolreturn.cocci CC: Matt Ranostay <mranostay@gmail.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-03iio: accel: bmc150: reset chip at init timeOlof Johansson1-0/+11
In at least one known setup, the chip comes up in a state where reading the chip ID returns garbage unless it's been reset, due to noise on the wires during system boot. All supported chips have the same reset method, and based on the datasheets they all need 1.3 or 1.8ms to recover after reset. So, do the conservative thing here and always reset the chip. Signed-off-by: Olof Johansson <olof@lixom.net> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-03iio: st_sensors: fix errorcheck for regulatorsLinus Walleij1-2/+2
We were checking the return code of vdd when we should be checking vdd_io. My mistake, mea culpa. Cc: Giuseppe BARBA <giuseppe.barba@st.com> Reported-by: Giuseppe BARBA <giuseppe.barba@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-03iio: stx104: Add IIO support for the ADC channelsWilliam Breathitt Gray5-35/+145
The Apex Embedded Systems STX104 features 16 channels of single-ended (8 channels of true differential) 16-bit analog input. Differential input configuration may be selected via a physical jumper on the device. Similarly, input polarity (unipolar/bipolar) is configured via a physical jumper on the device. Input gain selection is available to the user via software, thus allowing eight possible input ranges: +-10V, +-5V, +-2.5V, +-1.25V, 0 to 10V, 0 to 5V, 0 to 2.5V, and 0 to 1.25V. Four input gain configurations are supported: x1, x2, x4, and x8. This ADC resolution is 16-bits (1/65536 of full scale). Analog input samples are taken on software trigger; neither FIFO sampling nor interrupt triggering is supported by this driver. The Apex Embedded Systems STX104 is primarily an analog-to-digital converter device. The STX104 IIO driver was initially placed in the DAC directory because only the DAC portion of the STX104 was supported at the time. Now that ADC support has been added to the STX104 IIO driver, the driver should be moved to the more appropriate ADC directory. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-03iio: fix pressure data output unit in hid-sensor-attributesKweh, Hock Leong1-2/+2
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 <hock.leong.kweh@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-03iio: adc: ina2xx: remove unused debug field from chip global dataAlison Schofield1-5/+0
commit 1961bce76452 "iio: ina2xx: Remove trace_printk debug statements" removed the code that used the chip->prev_ns field. This patch cleans it up further by removing the unused field and assignments. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Cc: Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-03iio: trigger: allow immutable triggers to be assignedMatt Ranostay1-0/+20
There are times when an assigned trigger to a device shouldn't ever change after intialization. Examples of this being used is when an provider device has a trigger that is assigned to an ADC, which uses it populate data into a callback buffer. Signed-off-by: Matt Ranostay <matt@ranostay.consulting> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-09-03iio: sx9500: add final devicetree supportChristoph Fritz1-0/+7
This makes sx9500 driver usable on devicetree based platforms too. Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by: Vlad Dogaru <ddvlad@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>