The original reason for this behaviour is long gone and no current
drivers are making use of this function correctly. Note however, that
you would be very unlucky to actually hit the problem as it would
require a bus comms failure in the callback.

This dates back a long way.  The original board on which I did a lot
of early IIO development only supported edge interrupts, but some of the
sensors were level interrupt based.  As such, the lis3l02dq driver did
a dance with checking a GPIO to identify if it should retrigger.
That was an unsustainable hack so we later just stopped supporting interrupts
for that particular combination.

There are a number of drivers where a fault on a bus read in the
try_reenable() callback will result in them returning non 0 and
incorrectly then causing iio_trigger_poll() to be called.

Anyhow, this handling is unused and causing issues so let us rip it out.
Link: https://lore.kernel.org/linux-iio/20200813075358.13310-1-lars@metafoo.de/

After this the try_reenable() naming makes no sense, so as a follow up
patch I'll rename it to simply reenable().  I haven't done that here
as it will add noise to the fix for backporting.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Christian Eggers <ceggers@arri.de>
Link: https://lore.kernel.org/r/20200920132548.196452-2-jic23@kernel.org

In function iio_map_array_register() properly rewind in case of error.
Signed-off-by: NLino Sanfilippo <LinoSanfilippo@gmx.de>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/1606571059-13974-2-git-send-email-LinoSanfilippo@gmx.deSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Introduce an unlocked version of iio_map_array_unregister(). This function
can help to unwind in case of error while the iio_map_list_lock mutex is
held.
Signed-off-by: NLino Sanfilippo <LinoSanfilippo@gmx.de>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/1606571059-13974-1-git-send-email-LinoSanfilippo@gmx.deSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/501ff8187d2df584ec978c7e7ec5c445c3d0741c.1606642528.git.lorenzo@kernel.orgSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Add support to STM LSM6DSOP (acc + gyro) Mems sensor
https://www.st.com/resource/en/datasheet/lsm6dsop.pdfSigned-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/d3c459ad945ccd1a256f4a217128be214b0c024e.1606642528.git.lorenzo@kernel.orgSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Shrink st_lsm6dsx_sensor_settings table size moving wai address info in
id array and remove duplicated code
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/c43286938b2fe03ab3abdb5fc095ea6b950abcb1.1606557946.git.lorenzo@kernel.orgSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

at91_adc_probe_dt is now small enough to be merged back in at91_adc_probe.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Link: https://lore.kernel.org/r/20201128222818.1910764-8-alexandre.belloni@bootlin.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The trigger child nodes are not necessary anymore as they are defined
directly by the driver, depending on the compatible string.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Rob Herring <robh+dt@kernel.org>
Link: https://lore.kernel.org/r/20201128222818.1910764-7-alexandre.belloni@bootlin.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Move the available trigger definition back in the driver to stop cluttering
the device tree. There is no functional change except that it actually
fixes the available triggers for at91sam9rl as it inherited the list from
at91sam9260 but actually has the triggers from at91sam9x5.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Link: https://lore.kernel.org/r/20201128222818.1910764-6-alexandre.belloni@bootlin.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

There are a few things we would do differently in an ADC binding if we
were starting from scratch but we are stuck with what we have (which
made sense back when this was written!)

We may be able to tighten up some elements of this binding in the future
by careful checking of what values properties can actually take.

Note the unusual sign off chain is representative of the path this patch
took.

Jonathan wrote the patch, which was then included in a series by
Alexandre and ultimately applied by Jonathan.

[Alexandre Belloni: add sama5d3, remove atmel,adc-res and atmel,adc-res-names]
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Reviewed-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20201128222818.1910764-5-alexandre.belloni@bootlin.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Remove atmel,adc-res and atmel,adc-res-names as they are not necessary and
are handled by the driver. Also add sama5d3 to the list of possible chips.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Rob Herring <robh+dt@kernel.org>
Link: https://lore.kernel.org/r/20201128222818.1910764-4-alexandre.belloni@bootlin.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Move the possible resolution values back to the driver. This removes the
atmel,adc-res and atmel,adc-res-names properties, leaving only
atmel,adc-use-res. As atmel,adc-res-names had to contain "lowres" and
"highres", those where already the only allowed values for
atmel,adc-use-res.

Also introduce a new compatible string for the sama5d3 as this is the only
one with a different resolution. Also it doesn't even have the LOWRES
bit.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Link: https://lore.kernel.org/r/20201128222818.1910764-3-alexandre.belloni@bootlin.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The driver is DT only since commit ead1c9f3 ("iio: adc: at91_adc:
remove platform data and move defs in driver file"). Remove the leftover
platform_device_id array.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201128222818.1910764-2-alexandre.belloni@bootlin.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

There were a few parts of the example that did not conform to the
binding description and would not have worked with the Linux driver
as a result.  Fixed them whilst doing this conversion.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Acked-by: NMatt Ranostay <matt.ranostay@konsulko.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20201031181242.742301-11-jic23@kernel.org

Simple conversion using the new iio-consumers.yaml binding in the
dt-schema.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201031181242.742301-10-jic23@kernel.org

Simple binding so straight forward conversion, though did require
adding a separate binding document for the max1027 to reflect
its abilities to provide channels to consumers.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-9-jic23@kernel.org

The afe/voltage-divider.yaml example uses this device with 2 properties
not provided by trivial-devices.yaml (spi-max-frequency and #io-channel-cells)

Solve that by creating a more specific binding doc.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Philippe Reynes <tremyfr@yahoo.fr>
Link: https://lore.kernel.org/r/20201031181242.742301-8-jic23@kernel.org

Very simple binding. As such straight forward conversion.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-7-jic23@kernel.org

Note this includes a fix in the example where we had *-mul instead of
*-mult.  The binding doc and driver agree that it should be *-mult
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-6-jic23@kernel.org

Straight forward format conversion.  The example in here is fun in
that it has 2 separate provider / consumer pairs.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-5-jic23@kernel.org

We use this part in an example for the envelope detector. That showed
that we need to allow for the #io-channel-cells property which
trivial-devices.yaml does not.

It doesn't make sense to add that property to trivial-devices as
it only applies for those devices that can provide some sort of
DAC or ADC service to another device driver.  Hence solution will
be to pull some IIO devices out to have their own file on a case
by case basis.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-4-jic23@kernel.org

Txt to yaml format conversion.  I dropped the example section
describing the measurement ADC, as that isn't strictly part
of this binding.

Uses the new dt-schema/schema/iio/iio-consumer.yaml schema.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-3-jic23@kernel.org

File contained generic IIO wide bindings.
Now part of the external dt-schema repository.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031181242.742301-2-jic23@kernel.org

Also add additionalProperties: false for the child nodes.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Cc: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Link: https://lore.kernel.org/r/20201031182423.742798-4-jic23@kernel.org

This both ensures this binding is compliant with the generic properties
and reduces the amount we need to specify in this separate binding.

Whilst here mark the child node as additionalProperties: false
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Link: https://lore.kernel.org/r/20201031182423.742798-3-jic23@kernel.org

Each driver that uses this will need to use a $ref
We can't always enable it like most of the generic bindings due to
channel@X matching far more widely than IIO.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031182423.742798-2-jic23@kernel.org

This basically has same questions as for the afe4403.  We could combine
the two bindings, but as the drivers are separate and it would be a little
fiddly due to different buses let's keep the separating.
To repeat questions from the ti,afe4403 binding.

A few questions came up whilst converting this one.
1) What is actually required?
   - Checking Linux driver, interrupt is not, and the tx-supply could
     be supplied by a stub regulator as long as it's always on.
     As such I have reduced the required list to just compatible and reg.
2) What is the regulator called?
   - It's tx-supply in the binding doc, but the driver request tx_sup
     I will shortly send out a fix for the driver to match the binding
     doc which is the better choice of naming.

As Andrew's email is bouncing, I've put myself as temporary maintainer
for this binding until someone else steps up.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031184854.745828-9-jic23@kernel.org

A few questions came up whilst converting this one.
1) What is actually required?
  - Checking Linux driver, interrupt is not, and the tx-supply could
    be supplied by a stub regulator as long as it's always on.
    As such I have reduced the required list to just compatible and reg.
2) What is the regulator called?
  - It's tx-supply in the binding doc, but the driver requests tx_sup.
    I'll post a fix patch to change the driver to fix this as it makes
    little sense.

Andrew's email is bouncing so until someone else steps up I have
listed myself as maintainer for this binding.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031184854.745828-8-jic23@kernel.org

When updating the buffer demux, we will skip a scan element from the
device in the case `in_ind != out_ind` and we enter the while loop.
in_ind should only be refreshed with `find_next_bit()` in the end of the
loop.

Note, to cause problems we need a situation where we are skippig over
an element (channel not enabled) that happens to not have the same size
as the next element.   Whilst this is a possible situation we haven't
actually identified any cases in mainline where it happens as most drivers
have consistent channel storage sizes with the exception of the timestamp
which is the last element and hence never skipped over.

Fixes: 5ada4ea9 ("staging:iio: add demux optionally to path from device to buffer")
Signed-off-by: NNuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20201112144323.28887-1-nuno.sa@analog.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

iio_format_list() has two branches in a switch statement that are almost
identical. They only differ in the stride that is used to iterate through
the item list.

Consolidate this into a common code path to simplify the code.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20201114120000.6533-2-lars@metafoo.deSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The iio_format_avail_list() and iio_format_avail_range() functions are
almost identical. The only differences are that iio_format_avail_range()
expects a fixed amount of items and adds brackets "[ ]" around the output.

Refactor them into a common helper function. This improves the
maintainability of the code as it makes it easier to modify the
implementation of these functions.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20201114120000.6533-1-lars@metafoo.deSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

io-channel-ranges is a property for consumers of io-channels, not
providers.  Hence it is not relevant in this binding or the examples
given.

Recent changes to dt-schema result in this being reported as an error
as a dependency is enforced between this property and io-channels.
Reported-by: NRob Herring <robh@kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201115192951.1073632-3-jic23@kernel.org

io-channel-ranges is a property for io-channel consumers. Here
it is in an example of a provider of channels so doesn't do anything
useful.

Recent additions to dt-schema check this property is only provided
alongside io-channels which is not true here and hence an error is
reported.
Reported-by: NRob Herring <robh@kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Jishnu Prakash <jprakash@codeaurora.org>
Link: https://lore.kernel.org/r/20201115192951.1073632-2-jic23@kernel.org

The driver should assert reset by setting the gpio high, and
then release it by setting it the gpio low. This allows the
device tree (or other hardware definition) to specify how the
gpio is configured.

For example as open drain or push-pull depending on the
connected hardware.
Signed-off-by: NPhil Reid <preid@electromag.com.au>
Link: https://lore.kernel.org/r/20201124050014.4453-1-preid@electromag.com.auSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

These Bosch accelerometers have two supplies, VDD and VDDIO.
Add some rudimentary support to obtain and enable these
regulators during probe() and disable them during remove()
or on the errorpath.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201115205745.618455-3-linus.walleij@linaro.orgSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

This adds support for the BMA222 version of this sensor,
found in for example the Samsung GT-I9070 mobile phone.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201115205745.618455-2-linus.walleij@linaro.orgSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

These accelerometers have bindings used in the kernel and
several device trees but no proper bindings documentation.
Add it.

Also add a compatible for the BMA222 that I am right now
adding support for in the driver.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: devicetree@vger.kernel.org
Link: https://lore.kernel.org/r/20201115205745.618455-1-linus.walleij@linaro.orgSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Use a heap allocated memory for the SPI transfer buffer. Using stack memory
can corrupt stack memory when using DMA on some systems.

This change moves the buffer from the stack of the trigger handler call to
the heap of the buffer of the state struct. The size increases takes into
account the alignment for the timestamp, which is 8 bytes.

The 'data' buffer is split into 'tx_buf' and 'rx_buf', to make a clearer
separation of which part of the buffer should be used for TX & RX.

Fixes: af300848 ("iio:adc: Add common code for ADI Sigma Delta devices")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NAlexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20201124123807.19717-1-alexandru.ardelean@analog.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Return error in case no callback is provided to
`iio_channel_get_all_cb()`. There's no point in setting up a buffer-cb
if no callback is provided.
Signed-off-by: NNuno Sá <nuno.sa@analog.com>
Reviewed-by: NOlivier Moysan <olivier.moysan@st.com>
Link: https://lore.kernel.org/r/20201121161457.957-3-nuno.sa@analog.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Adapt STM32 DFSDM driver to a change in iio_channel_get_all_cb() API.
The callback pointer becomes a requested parameter of this API,
so add a dummy callback to be given as parameter of this function.
However, the stm32_dfsdm_get_buff_cb() API is still used instead,
to optimize DMA transfers.
Signed-off-by: NOlivier Moysan <olivier.moysan@st.com>
Signed-off-by: NNuno Sá <nuno.sa@analog.com>
Acked-by: NMark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20201121161457.957-2-nuno.sa@analog.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>