Very simple binding that we could move into trivial-devices.yaml
with a small loss of documentation.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20201031184854.745828-15-jic23@kernel.org

This could have gone in trivial-devices.yaml, but there was a datasheet
link so I've given it a minimal file of it's own.
Very simple binding and so a very simple conversion.

Oleksandr's email address is bouncing so I've put myself as fallback
maintainer until someone else steps forward.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031184854.745828-14-jic23@kernel.org

Straight forward conversion, but there are a few generic properties
in here like wakeup-source which should probably have schema in a
more generic location.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/20201031184854.745828-13-jic23@kernel.org

Alexandru is currently listed as maintainer on basis of last person
to touch the binding.

Whilst the driver only uses one interrupt, the hardware can route events
to one and dataready signal to the other so we should allow for either
1 or 2 interrupts.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20201031184854.745828-12-jic23@kernel.org

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

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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20201031184854.745828-10-jic23@kernel.org

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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031184854.745828-7-jic23@kernel.org

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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Cc: Gabriel Capella <gabriel@capella.pro>
Cc: Alexandru Ardelean <Alexandru.Ardelean@analog.com>
Link: https://lore.kernel.org/r/20201031184854.745828-6-jic23@kernel.org

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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Chris Coffey <cmc@babblebit.net>
Link: https://lore.kernel.org/r/20201031184854.745828-5-jic23@kernel.org

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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-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

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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20201031184854.745828-4-jic23@kernel.org

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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Matheus Tavares <matheus.bernardino@usp.br>
Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20201031184854.745828-2-jic23@kernel.org

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: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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 <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20201117103753.8450-1-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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 <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20201119141806.84827-1-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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 <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20201119141729.84185-1-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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: Alexandru Ardelean <alexandru.ardelean@analog.com>
Tested-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Link: https://lore.kernel.org/r/20201119142720.86326-1-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The iio_buffer_set_attrs() is no longer used in the drivers, so it can be
removed now.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-10-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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 <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-9-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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 <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-8-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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 <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-7-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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 <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-6-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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 <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-5-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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 <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-4-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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 <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-3-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-2-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

No need to maintain a separate document for such a simple binding.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031182922.743153-8-jic23@kernel.org

Extremely simple binding so no need to maintain a separate file.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Jandy Gou <qingsong.gou@ck-telecom.com>
Link: https://lore.kernel.org/r/20201031182922.743153-7-jic23@kernel.org

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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Simon Horman <horms+renesas@verge.net.au>
Link: https://lore.kernel.org/r/20201031182922.743153-6-jic23@kernel.org

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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Slawomir Stepien <sst@poczta.fm>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Maury Anderson <maury.anderson@rockwellcollins.com>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Cc: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20201031182922.743153-5-jic23@kernel.org

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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Slawomir Stepien <sst@poczta.fm>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20201031182922.743153-4-jic23@kernel.org

Very simple binding so no need to maintain a separate file.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Sebastien Bourdelin <sebastien.bourdelin@gmail.com>
Cc: Himanshu Jha <himanshujha199640@gmail.com>
Link: https://lore.kernel.org/r/20201031182922.743153-3-jic23@kernel.org

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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Andreas Brauchli <andreas.brauchli@sensirion.com>
Link: https://lore.kernel.org/r/20201031182922.743153-2-jic23@kernel.org

Simple conversion from txt to yaml.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://lore.kernel.org/r/20201031134110.724233-30-jic23@kernel.org

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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20201031134110.724233-29-jic23@kernel.org

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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031134110.724233-28-jic23@kernel.org

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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-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

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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Crt Mori <cmo@melexis.com>
Cc: Crt Mori <cmo@melexis.com>
Link: https://lore.kernel.org/r/20201031134110.724233-26-jic23@kernel.org

Simple conversion from txt to yaml.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Crt Mori <cmo@melexis.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Link: https://lore.kernel.org/r/20201031134110.724233-25-jic23@kernel.org