- 03 Dec, 2020 40 commits
-
-
Jonathan Cameron authored
As we no longer support a try again if we cannot reenable the trigger rename the function to reflect this. Also we don't do anything with the value returned so stop it returning anything. For the few drivers that didn't already print an error message in this patch, add such a print. Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by:
Lars-Peter Clausen <lars@metafoo.de> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Christian Oder <me@myself5.de> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Nishant Malpani <nish.malpani25@gmail.com> Cc: Daniel Baluta <daniel.baluta@oss.nxp.com> Link: https://lore.kernel.org/r/20200920132548.196452-3-jic23@kernel.org
-
Jonathan Cameron authored
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:
-
Lino Sanfilippo authored
In function iio_map_array_register() properly rewind in case of error. Signed-off-by:
Lino Sanfilippo <LinoSanfilippo@gmx.de> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1606571059-13974-2-git-send-email-LinoSanfilippo@gmx.deSigned-off-by:
-
Lino Sanfilippo authored
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:
-
Lorenzo Bianconi authored
Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/501ff8187d2df584ec978c7e7ec5c445c3d0741c.1606642528.git.lorenzo@kernel.orgSigned-off-by:
-
Lorenzo Bianconi authored
Add support to STM LSM6DSOP (acc + gyro) Mems sensor https://www.st.com/resource/en/datasheet/lsm6dsop.pdfSigned-off-by:
-
Lorenzo Bianconi authored
Shrink st_lsm6dsx_sensor_settings table size moving wai address info in id array and remove duplicated code Signed-off-by:
-
Alexandre Belloni authored
at91_adc_probe_dt is now small enough to be merged back in at91_adc_probe. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20201128222818.1910764-8-alexandre.belloni@bootlin.comSigned-off-by:
-
Alexandre Belloni authored
The trigger child nodes are not necessary anymore as they are defined directly by the driver, depending on the compatible string. Signed-off-by:
-
Alexandre Belloni authored
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:
-
Jonathan Cameron authored
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:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Alexandre Belloni authored
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:
-
Alexandre Belloni authored
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:
-
Alexandre Belloni authored
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:
-
Jonathan Cameron authored
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:
Matt Ranostay <matt.ranostay@konsulko.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Link: https://lore.kernel.org/r/20201031181242.742301-11-jic23@kernel.org
-
Jonathan Cameron authored
Simple conversion using the new iio-consumers.yaml binding in the dt-schema. Signed-off-by:
-
Jonathan Cameron authored
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:
-
Jonathan Cameron authored
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:
-
Jonathan Cameron authored
Very simple binding. As such straight forward conversion. Signed-off-by:
-
Jonathan Cameron authored
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:
-
Jonathan Cameron authored
Straight forward format conversion. The example in here is fun in that it has 2 separate provider / consumer pairs. Signed-off-by:
-
Jonathan Cameron authored
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:
-
Jonathan Cameron authored
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:
-
Jonathan Cameron authored
File contained generic IIO wide bindings. Now part of the external dt-schema repository. Signed-off-by:
-
Jonathan Cameron authored
Also add additionalProperties: false for the child nodes. Signed-off-by:
-
Jonathan Cameron authored
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:
-
Jonathan Cameron authored
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:
-
Jonathan Cameron authored
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: -
Jonathan Cameron authored
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: -
Nuno Sá authored
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:
Nuno 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:
-
Lars-Peter Clausen authored
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:
-
Lars-Peter Clausen authored
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:
-
Jonathan Cameron authored
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:
Krzysztof Kozlowski <krzk@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201115192951.1073632-3-jic23@kernel.org
-
Jonathan Cameron authored
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:
Bjorn 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
-
Phil Reid authored
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:
Phil Reid <preid@electromag.com.au> Link: https://lore.kernel.org/r/20201124050014.4453-1-preid@electromag.com.auSigned-off-by:
-
Linus Walleij authored
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:
-
Linus Walleij authored
This adds support for the BMA222 version of this sensor, found in for example the Samsung GT-I9070 mobile phone. Signed-off-by:
-
Linus Walleij authored
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:
-
Lars-Peter Clausen authored
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:
Alexandru 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:
-
Nuno Sá authored
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:
Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20201121161457.957-3-nuno.sa@analog.comSigned-off-by:
-
