- 22 Nov, 2020 8 commits
-
-
Jonathan Cameron authored
Straight forward binding. Title was a bit of a challenge to keep short as this binding covers sensors for two entirely different purposes. Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by:
Rob Herring <robh@kernel.org> Acked-by:
Matt Ranostay <matt.ranostay@konsulko.com> Cc: Matt Ranostay <mranostay@gmail.com> Link: https://lore.kernel.org/r/20201031184854.745828-11-jic23@kernel.org
-
Jonathan Cameron authored
Straight forward conversion. As with other bindings I've dropped any standrd description, but kept the unusual bits, in thisscase the maxim,led-current-microamp and it's description. Signed-off-by:
-
Jonathan Cameron authored
Renamed to be more specific as I would be surprised if this is the only sensorhub Samsung have ever shipped. Fixed missing reg property in the example Karol's email address from original patch is bouncing, so I've put myself as maintainer until someone else steps up. Signed-off-by:
-
Jonathan Cameron authored
The example in this one had a completely wrong compatible so I've fixed that. Otherwise, a fairly simple conversion. Note the driver itself is still in staging. Looking back at the last discussion around this, I think we were just waiting for some test results on some refactors. As such the binding should be stable even if the driver might need a little more love and attention. Signed-off-by:
-
Jonathan Cameron authored
A simple binding that I almost just move to trivial devices. The small amount of additional documentation and relatively large number of compatible entries convinced me to suggest we keep this one separately documented. Signed-off-by:
-
Jonathan Cameron authored
Simple direct conversion from txt to yaml as part of a general aim of converting all IIO bindings to this machine readable format. Signed-off-by:
Phil Reid <preid@electromag.com.au> Cc: Phil Reid <preid@electromag.com.au> Link: https://lore.kernel.org/r/20201031184854.745828-3-jic23@kernel.org
-
Jonathan Cameron authored
This binding is very simple, but I think the very large number of compatible values make it unsuitable for moving to trivial-devices.yaml. Main change in the conversion was reordering the compatible list to numerical order. Signed-off-by:
Slawomir Stepien <sst@poczta.fm> Link: https://lore.kernel.org/r/20201031184854.745828-4-jic23@kernel.org
-
Jonathan Cameron authored
Simple binding with a good description of why the spi-max-frequency is, in practice not as high as the datasheet implies. I've set the maximum as per the value established in the description. Signed-off-by:
-
- 21 Nov, 2020 15 commits
-
-
Alexandru Ardelean authored
It seems that when this was tested the happy case was more tested. A few of the userspace apps rely on this returning negative error codes in case an ioctl() is not available. When running multiple ioctl() handlers or when calling an ioctl() that doesn't exist, IIO_IOCTL_UNHANDLED is returned. In that case -EINVAL should be returned. Fixes: 8dedcc3e ("iio: core: centralize ioctl() calls to the main chardev") Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201117095154.7189-1-alexandru.ardelean@analog.comSigned-off-by:
-
Alexandru Ardelean authored
The change is mostly cosmetic. This organizes the order of assignment of the members of 'iio_buffer_fileops' to be similar to the one as defined in the 'struct file_operations' type. Signed-off-by:
-
Alexandru Ardelean authored
There is no matching spi_get_drvdata() in the driver. This looks like a left-over from before the driver was converted to device-managed functions. Signed-off-by:
-
Alexandru Ardelean authored
There is no matching spi_get_drvdata() in the driver. This looks like a left-over from before the driver was converted to device-managed functions. Signed-off-by:
-
Alexandru Ardelean authored
This seems to have been copied from a driver that calls spi_set_drvdata() but doesn't call spi_get_drvdata(). Setting a private object on the SPI device's object isn't necessary if it won't be accessed. This change removes the spi_set_drvdata() call. Signed-off-by:
Marcelo Schmitt <marcelo.schmitt1@gmail.com> Reviewed-by:
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://github.com/KSPP/linux/issues/115 Link: https://lore.kernel.org/r/b3c1c3f9c76f2f0e832f956587f227e44af57d3d.1605896060.git.gustavoars@kernel.orgSigned-off-by:
-
Alexandru Ardelean authored
The iio_buffer_set_attrs() is no longer used in the drivers, so it can be removed now. Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200929125949.69934-10-alexandru.ardelean@analog.comSigned-off-by:
-
Alexandru Ardelean authored
This change switches to the new iio_triggered_buffer_setup_ext() function and removes the iio_buffer_set_attrs() call, for assigning the HW FIFO attributes to the buffer. Signed-off-by:
-
Alexandru Ardelean authored
This change switches to the new devm_iio_triggered_buffer_setup_ext() function and removes the iio_buffer_set_attrs() call, for assigning the HW FIFO attributes to the buffer. Signed-off-by:
-
Alexandru Ardelean authored
This change switches to the new devm_iio_triggered_buffer_setup_ext() function and removes the iio_buffer_set_attrs() call, for assigning the HW FIFO attributes to the buffer. Signed-off-by:
-
Alexandru Ardelean authored
This change switches to the new iio_triggered_buffer_setup_ext() function and removes the iio_buffer_set_attrs() call, for assigning the HW FIFO attributes to the buffer. Signed-off-by:
-
Alexandru Ardelean authored
This change switches to the new devm_iio_triggered_buffer_setup_ext() function and removes the iio_buffer_set_attrs() call, for assigning the HW FIFO attributes to the buffer. Signed-off-by:
-
Alexandru Ardelean authored
This change adds a parameter to the {devm_}iio_triggered_buffer_setup() functions to assign the extra sysfs buffer attributes that are typically assigned via iio_buffer_set_attrs(). The functions also get renamed to iio_triggered_buffer_setup_ext() & devm_iio_triggered_buffer_setup_ext(). For backwards compatibility the old {devm_}iio_triggered_buffer_setup() functions are now macros wrap the new (renamed) functions with NULL for the buffer attrs. The aim is to remove iio_buffer_set_attrs(), so in the iio_triggered_buffer_setup_ext() function the attributes are assigned directly to 'buffer->attrs'. When adding multiple IIO buffers per IIO device, it can be pretty cumbersome to first allocate a set of buffers, then to dig them out of IIO to assign extra attributes (with iio_buffer_set_attrs()). Naturally, the best way would be to provide them at allocation time, which is what this change does. At this moment, buffers allocated with {devm_}iio_triggered_buffer_setup() are the only ones in mainline IIO to call iio_buffer_set_attrs(). Signed-off-by: -
Alexandru Ardelean authored
This change is mostly cosmetic, but it's also a pre-cursor to the the change for 'iio_buffer_set_attrs()', where the helper gets updated to better support multiple IIO buffers for 1 IIO device. The only functional change is that the error message for the trigger alloc failure is bound to the parent device vs the IIO device object. Also, the new at91_adc_buffer_and_trigger_init() function was moved after the definition of the 'at91_adc_fifo_attributes'. Signed-off-by:
-
Alexandru Ardelean authored
The iio_buffer_set_attrs() helper will be removed in this series. So, just assign the attributes of the DMAEngine buffer logic directly. This is IIO buffer core context, so there is direct access to the buffer->attrs object. Signed-off-by:
-
- 16 Nov, 2020 17 commits
-
-
Jonathan Cameron authored
No need to maintain a separate document for such a simple binding. Signed-off-by:
-
Jonathan Cameron authored
Extremely simple binding so no need to maintain a separate file. Signed-off-by:
-
Jonathan Cameron authored
This binding is so simple there is no obvious advantage in maintaining a separate binding doc file for it. As such, move it to trivial-devices.yaml Signed-off-by:
-
Jonathan Cameron authored
Simple SPI binding that doesn't need a separate file. During conversion I looked up the individual part number descriptions in the datasheet so that we could give slightly more detail in trivial-device.yaml. Signed-off-by:
-
Jonathan Cameron authored
Simple binding where there is no obvious benefit in maintaining a separate file. Hence document in trivial-devices.yaml and drop the txt file. Signed-off-by:
-
Jonathan Cameron authored
Very simple binding so no need to maintain a separate file. Signed-off-by:
-
Jonathan Cameron authored
The binding for this device and the sgpc3 is very simple so lets not maintain a seperate document for this one. Of course we can always add a document again if the binding becomes more complex in future. Signed-off-by:
-
Jonathan Cameron authored
Simple conversion from txt to yaml. Signed-off-by:
Manivannan Sadhasivam <mani@kernel.org> Link: https://lore.kernel.org/r/20201031134110.724233-30-jic23@kernel.org
-
Jonathan Cameron authored
Given we already have another maxim thermocouple driver that isn't covered by this binding it seems a better idea to chose to name it after a specific part. I added an additional example for the maxim,max6755 to illustrate the need for spi-cpha for that part. Signed-off-by:
-
Jonathan Cameron authored
Simple txt to yaml conversion of this binding. Paresh Chaudhary's email is bouncing so for now I've listed myself as maintainer. Signed-off-by:
-
Jonathan Cameron authored
The existing binding description brings little value and the similar meas,* parts are in trivial-devices.yaml so move this one there to join them. Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20201031134110.724233-27-jic23@kernel.org
-
Jonathan Cameron authored
Technically this could have gone in trivial-devices.yaml, but I have kept it as a separate binding due to the detailed additional description from the text file. Signed-off-by:
Crt Mori <cmo@melexis.com> Cc: Crt Mori <cmo@melexis.com> Link: https://lore.kernel.org/r/20201031134110.724233-26-jic23@kernel.org
-
Jonathan Cameron authored
Simple conversion from txt to yaml. Signed-off-by:
-
Jonathan Cameron authored
I have put Michael as maintainer on this one. Happy to change it to someone else though. One issue in here, is I cannot have an example with a negative limit on the range. There are very few such yaml bindings in existence but the thermal-zones.yaml has the same problem. If there is any means of fixing this let me know. For now I'm sticking to positive range values in the example. Signed-off-by:
-
Jonathan Cameron authored
Very similar binding to that for the ADC on the same device. Conversion from txt to yaml format. Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Link: https://lore.kernel.org/r/20201031134110.724233-23-jic23@kernel.org
-
Jonathan Cameron authored
Simple txt to yaml conversion for this binding description. Signed-off-by:
-
Jonathan Cameron authored
I'm not sure vdd-supply absolutely has to be provided if vref-supply is, but as the previous binding docs stated it was required it seems reasonable to leave it as such. Signed-off-by:
-
