- Dec 04, 2020
-
-
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 <Jonathan.Cameron@huawei.com> Reviewed-by:
Rob Herring <robh@kernel.org> Cc: Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20201031181242.742301-3-jic23@kernel.org
-
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 <lars@metafoo.de> Link: https://lore.kernel.org/r/20201114120000.6533-2-lars@metafoo.de 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.au Signed-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 <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201115205745.618455-3-linus.walleij@linaro.org 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.com Signed-off-by:
-
Olivier Moysan authored
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:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20201121161457.957-2-nuno.sa@analog.com Signed-off-by:
-
Lorenzo Bianconi authored
Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/9579804f52ccab74a5ca5c7a55b5072b7304bea9.1606045688.git.lorenzo@kernel.org Signed-off-by:
-
Lorenzo Bianconi authored
Like all other ST sensors, hts221 devices have VDD power line. Introduce VDD voltage regulator to control it. Signed-off-by:
-
William Breathitt Gray authored
Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by:
Kamel Bouhara <kamel.bouhara@bootlin.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20201121185824.451477-1-vilhelm.gray@gmail.com Signed-off-by:
-
Alexandru Ardelean authored
'st->ext_ref' & 'st->reg' are both non-zero/non-null at the same time, so logically the code isn't broken. But it is more correct to check that 'st->reg' is non-null, since we make sure that the regulator is NULL (in probe) in case one isn't defined. Signed-off-by:
-
- Nov 28, 2020
-
-
Alexandru Ardelean authored
This change converts the probe of this driver to use device-managed register functions, and a devm_add_action_or_reset() for the regulator disable. With this, the exit & error paths can be removed. Another side-effect is that this should avoid some static-analyzer's check with respect to a potential null dereference of the regulator. The null dereference isn't likely to happen (under normal operation), so there isn't a requirement to have this fixed/backported in other releases. As a note: this is removing spi_set_drvdata() since there is no other spi_get_drvdata() (or dev_get_drvdata()) call that need it. Signed-off-by:
-
- Nov 25, 2020
-
-
Lorenzo Bianconi authored
Signed-off-by:
-
Lorenzo Bianconi authored
Like all other ST sensors, st_lsm6dsx devices have VDD and VDDIO power lines. Introduce voltage regulators to control them. Signed-off-by:
-
Jonathan Cameron authored
So far, the thermocouple-type property described in here is only used in a single driver. Whilst I would like it to be more generally used that hasn't happened yet and I don't see a reason to maintain this small file in the hope that it happens. I pushed for this generic binding in the first place. Hopefully we can bring it back at somepoint. Signed-off-by:
-
Jonathan Cameron authored
This is a large but fairly simple binding. It may well be possible to constrain some of the properties more than currently done, but that would involve diving into datasheets for the supported parts. Hence for this initial conversion just use the information that was in the txt file. Signed-off-by:
-
Jonathan Cameron authored
This binding document covers a very large number of different sensors. As such the existing documentation is less specific than it could be (such as which devices have 2 interrupt pin options). That can be improved later. Denis, are you happy to be listed as maintainer for this one? If not feel free to suggestion someone else. Signed-off-by:
Denis Ciocca <denis.ciocca@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Link: https://lore.kernel.org/r/20201031184854.745828-45-jic23@kernel.org
-
Jonathan Cameron authored
Very simple direct conversion of existing txt file. Signed-off-by:
-
Jonathan Cameron authored
Simple binding so mostly straight forward to convert. Original binding was unclear on how many interrupts there are. The device has two such lines, whilst I believe the driver currently only uses one at a time. The binding should allow both to be specified. Signed-off-by:
-
Jonathan Cameron authored
Very simple binding hence a straight forward conversion. Signed-off-by:
-
Jonathan Cameron authored
One question in here is whether we want to constrain the number of interrupts. Some parts definitely only have 1 such pin, and others 2 pins but I can not find information on the bma254. Oleksandr's email address is bouncing so I've listed myself as maintainer for this binding until someone else steps up. Signed-off-by:
-
Jonathan Cameron authored
This is a more complex binding. Whilst conversion is straight forward I am unsure if the full nature of required properties has been captured. Signed-off-by:
-
Jonathan Cameron authored
Simple binding so straight forward format conversion. Signed-off-by:
Dan Murphy <dmurphy@ti.com> Link: https://lore.kernel.org/r/20201031184854.745828-38-jic23@kernel.org
-
Jonathan Cameron authored
Straight forward conversion. Not heard from Ivan in a while so if the email bounces, I'll change the maintainer to myself for this binding unless anyone else comes forwards. Signed-off-by:
-
Jonathan Cameron authored
Renamed to match a listed compatible rather than relying on wildcards with all their usual problems. Dropped the reference supply as a requirement as at least one dtsi doesn't include it and the example never did. Signed-off-by:
-
Jonathan Cameron authored
Simple conversion of the binding doc for this subnode of the palmas PMIC. Given age of driver and lack interaction with original authors, I've guessed at Tony for a maintainer on this one. Tony, if you are happy with that great, otherwise I can default back to myself. Signed-off-by:
-
Jonathan Cameron authored
The current driver and indeed binding are named after a part that they do not list in the compatible. Hence renamed the binding to reflect one that does. >From the driver it looks like there is a lot more backwards compatibility than the binding currently reflects. We could consider expressing that more explicitly in the yaml for the compatible property. I have added one explicit pair that was present in the upstream dtsi files. I added Matthias alongside Zhiyong Tao because I don't think Zhiyong Tao has reviewed recent patches. Please let me know if this isn't the right thing to do. Signed-off-by:
-
Jonathan Cameron authored
A few questions came up in this one. 1) Why does the txt file document io-channel-ranges as a required property. That property is for iio-channel consumers, and this is a provider. I have dropped it. 2) The example had an @180a6000 for the ADC but given it uses syscon for all access, it doesn't have its own reg etc. I've dropped that from the binding example. Note this example was lifted directly from bcm-cygnus.dtsi so both issues are present there as well. Signed-off-by:
-
