IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Kerneldoc expects attributes/parameters to be in '@*.: ' format.
Fixes the following W=1 kernel build warning(s):
drivers/iio/gyro/adis16080.c:49: warning: Function parameter or member 'lock' not described in 'adis16080_state'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Barry Song <21cnbao@gmail.com>
Link: https://lore.kernel.org/r/20200716135928.1456727-13-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
File headers are not good candidates for kerneldoc.
Fixes the following W=1 kernel build warning(s):
drivers/iio/dummy/iio_dummy_evgen.c:30: warning: Cannot understand * @regs: irq regs we are faking
on line 30 - I thought it was a doc line
drivers/iio/dummy/iio_dummy_evgen.c:42: warning: Function parameter or member 'irq_sim_domain' not described in 'iio_dummy_eventgen'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200716135928.1456727-16-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/ad7949.c:58: warning: Function parameter or member 'indio_dev' not described in 'ad7949_adc_chip'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Charles-Antoine Couret <charles-antoine.couret@essensium.com>
Link: https://lore.kernel.org/r/20200716135928.1456727-18-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Misspelling, missing description.
Fixes the following W=1 kernel build warning(s):
drivers/iio/dac/ad5064.c:71: warning: bad line: internal vref.
drivers/iio/dac/ad5064.c:83: warning: Function parameter or member 'channels' not described in 'ad5064_chip_info'
drivers/iio/dac/ad5064.c:125: warning: Function parameter or member 'lock' not described in 'ad5064_state'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20200716135928.1456727-20-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fixes the following W=1 kernel build warning(s):
drivers/iio/dac/ad7303.c:49: warning: Function parameter or member 'vdd_reg' not described in 'ad7303_state'
drivers/iio/dac/ad7303.c:49: warning: Function parameter or member 'vref_reg' not described in 'ad7303_state'
drivers/iio/dac/ad7303.c:49: warning: Function parameter or member 'lock' not described in 'ad7303_state'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20200716135928.1456727-31-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock, to protect against any other accesses during the
reading of sample. Reading a sample requires multiple consecutive regmap
operations and a completion callback, so this requires that no other
read occurs until it completes.
This is part of a bigger cleanup.
Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200916092928.78026-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
VL53L0X can be configured to use interrupt pin (GPIO1)
to notify host about readiness of new measurement.
If interrupt pin is not specified, driver still uses polling.
Signed-off-by: Ivan Drobyshevskyi <drobyshevskyi@gmail.com>
Link: https://lore.kernel.org/r/20200916074458.873359-2-drobyshevskyi@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This enables use of the driver with ACPI PRP0001 and also removes
an antipattern that I am trying to clear out of IIO to avoid
it being copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-39-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: David Barksdale <dbarksdale@uplogix.com>
Link: https://lore.kernel.org/r/20200910173242.621168-38-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Link: https://lore.kernel.org/r/20200910173242.621168-37-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200910173242.621168-36-jic23@kernel.org
Both would result in only a small size saving. For simplicity it
is best to remove them. I also wish to remove both these antipatterns
from IIO.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tested-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Link: https://lore.kernel.org/r/20200910173242.621168-35-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-34-jic23@kernel.org
This change allows the driver to be used with ACPI PRP0001 and removes
an antipattern that I want to avoid being copied into new IIO drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-33-jic23@kernel.org
This makes the existing code easier to read and will make the following
patch a little simpler.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-32-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-31-jic23@kernel.org
This change allow the driver to be used with ACPI PRP0001 and removes
an antipattern that I want to avoid being copied into new IIO drivers.
The handling of match_data uses a different approach as
device_get_match_data() doesn't distinguish between no match, and
a match but with NULL data.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-30-jic23@kernel.org
Avoids lots of repetition of &client->dev and will make the next
patch tidier.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-29-jic23@kernel.org
This change allow the driver to be used with ACPI PRP0001 and removes
an antipattern that I want to avoid being copied into new IIO drivers.
The handling of match_data uses a different approach as
device_get_match_data doesn't distinguish between no match, and
a match but with NULL data.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andreas Brauchli <andreas.brauchli@sensirion.com>
Link: https://lore.kernel.org/r/20200910173242.621168-28-jic23@kernel.org
This cleans up the code at bit, but is primarily here as a precusor
to the next patch. I've only done this for the two functions
which use the dev pointer repeatedly.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andreas Brauchli <andreas.brauchli@sensirion.com>
Link: https://lore.kernel.org/r/20200910173242.621168-27-jic23@kernel.org
of_match_ptr() prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver and use generic fw accessors to check
if there is a fw_node and get the id.
It might be neater to use pointers rather than indexes for
the device_data but that is another issue and should be handled
separately.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-26-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-25-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200910173242.621168-24-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Manivannan Sadhasivam <manivannanece23@gmail.com>
Link: https://lore.kernel.org/r/20200910173242.621168-23-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Link: https://lore.kernel.org/r/20200910173242.621168-22-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Gregor Boirie <gregor.boirie@parrot.com>
Link: https://lore.kernel.org/r/20200910173242.621168-21-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Link: https://lore.kernel.org/r/20200910173242.621168-20-jic23@kernel.org
These prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Tomasz Duszynski <tduszyns@gmail.com>
Link: https://lore.kernel.org/r/20200910173242.621168-19-jic23@kernel.org
These prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Link: https://lore.kernel.org/r/20200910173242.621168-18-jic23@kernel.org
This change allows use of this driver with ACPI via PRP0001 and removes
an example of an anti pattern I'm trying to remove from IIO.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-17-jic23@kernel.org
These prevent the use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Link: https://lore.kernel.org/r/20200910173242.621168-16-jic23@kernel.org
These prevent the use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Lukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/20200910173242.621168-15-jic23@kernel.org
This enables use of ACPI PRP0001 and removes an antipattern I am
trying to stop people copying in IIO.
This particular case is more complex than most because it allowed
probing via sysfs with out a fwnode but would presumably always
have then failed. Now the code will assume that properties are
the defaults if not specified or the firmware node is not present.
This relaxation of the constraints should not break any existing
cases and may enable some new ones.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Link: https://lore.kernel.org/r/20200910173242.621168-14-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Also add mod_devicetable.h include given struct of_device_id is
declared there.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20200910173242.621168-13-jic23@kernel.org
These result in a very small reduction in driver size, but at the
cost of more complex build and slightly harder to read code.
In the case of of_match_ptr it also prevents use of PRP0001
ACPI based identification. In this particular case we have
a valid ACPI/PNP ID that I am assuming was issued by Analog
Devices. That should be used in preference to PRP0001 but doesn't
mean we should prevent that route.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20200910173242.621168-12-jic23@kernel.org
These result in a very small reduction in driver size, but at the
cost of more complex build and slightly harder to read code.
In the case of of_match_ptr it also prevents use of PRP0001
ACPI based identification. In this particular case we have
a valid ACPI/PNP ID that I am assuming was issued by Analog
Devices. That should be used in preference to PRP0001 but doesn't
mean we should prevent that route.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20200910173242.621168-11-jic23@kernel.org
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Link: https://lore.kernel.org/r/20200910173242.621168-10-jic23@kernel.org
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Also switch to device_get_match_data() from of_ variant and adjust
headers to reflect the change.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20200910173242.621168-9-jic23@kernel.org
This change allows the use of the driver with ACPI via PRP0001
and remove an example of an anti pattern I'm trying to remove from IIO.
Also adjust includes to reflect this change.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20200910173242.621168-8-jic23@kernel.org
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Also use device_get_match_data() rather than devicetree only version.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20200910173242.621168-7-jic23@kernel.org
Given that an ACPI binding must start with 3 or 4 capitals,
this cannot represent a valid binding.
It seems unlikely anything out there is using it.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
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/20200910173242.621168-6-jic23@kernel.org
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Whilst this driver has an ACPI binding, it is not of a form
that is valid under ACPI so will be dropped shortly.
Also switch to device_get_match_data() and switch headers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
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/20200910173242.621168-5-jic23@kernel.org
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Drop them to remove this restriction.
Also switch headers to reflect this change.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20200910173242.621168-4-jic23@kernel.org
This patch fixes the device name typo.
Fixes: 951ad47003 ("iio: adc: ad7124: move chip ID & name on the chip_info table")
Signed-off-by: Mircea Caprioru <mircea.caprioru@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200902134222.28357-1-mircea.caprioru@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Drop them to remove this restriction.
Also switch of.h for mod_devicetable.h include given use of
struct of_device_id which is defined in that header.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20200910173242.621168-3-jic23@kernel.org
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Drop them to remove this restriction.
Also added mod_devicetable.h include given use of struct of_device_id
which is defined in that header.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Phil Reid <preid@eletromag.com.au>
Link: https://lore.kernel.org/r/20200910173242.621168-2-jic23@kernel.org
I'd like to be enable W=1 for all IIO builds as it catches real issues as well
as more minor documentation issues such as this (also good to fix though!)
drivers/iio/imu/adis16400.c:183: warning: Function parameter or member 'avail_scan_mask' not described in 'adis16400_state'
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200913132115.800131-2-jic23@kernel.org
Currently the iio_buffer_{alloc,free}_sysfs_and_mask() take 'indio_dev' as
primary argument. This change splits the main logic into a private function
that takes an IIO buffer as primary argument.
That way, the functions can be extended to configure the sysfs for multiple
buffers.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200917125951.861-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use only one line for the closing bracket of the last entry and the
opening bracket for the next one to keep the style across the whole
array consistent. Also add a "sentinel" comment to the last entry and
remove the comma to ensure that there won't be any entry after it.
No functional changes.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20200915192621.13202-1-martin.blumenstingl@googlemail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
We should probably print what the expected chip-ID is. We already have
that information available, based on the device specified via
device-tree.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200916083128.73729-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Drop `adis_setup_buffer_and_trigger()`. All users were updated to use
the devm version of this function. This avoids having almost the same
code repeated.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20200915120258.161587-11-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use the adis managed device functions to setup the buffer and the trigger.
The ultimate goal will be to completely drop the non devm version from
the lib.
Since we are here, drop the `.remove` callback by further using devm
functions.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20200915120258.161587-8-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use the adis managed device functions to setup the buffer and the trigger.
The ultimate goal will be to completely drop the non devm version from
the lib.
Since we are here, drop the `.remove` callback by further using devm
functions.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20200915120258.161587-7-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use the adis managed device functions to setup the buffer and the trigger.
The ultimate goal will be to completely drop the non devm version from
the lib.
Since we are here, drop the `.remove` callback by further using devm
functions.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20200915120258.161587-6-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use the adis managed device functions to setup the buffer and the trigger.
The ultimate goal will be to completely drop the non devm version from
the lib.
Since we are here, drop the `.remove` callback by further using devm
functions.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20200915120258.161587-5-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use the adis managed device functions to setup the buffer and the trigger.
The ultimate goal will be to completely drop the non devm version from
the lib.
Since we are here, drop the `.remove` callback by further using devm
functions.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20200915120258.161587-4-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use the adis managed device functions to setup the buffer and the trigger.
The ultimate goal will be to completely drop the non devm version from
the lib.
Since we are here, drop the `.remove` callback by further using devm
functions.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20200915120258.161587-3-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use the adis managed device functions to setup the buffer and the trigger.
The ultimate goal will be to completely drop the non devm version from
the lib.
Since we are here, drop the `.remove` callback by further using devm
functions.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20200915120258.161587-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock.
The lock protect the state of the device from potential concurrent writes.
The device is configured via a sequence of SPI writes, and this lock is
meant to prevent the start of another sequence before another one has
finished.
This is part of a bigger cleanup.
Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200916092731.77220-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state from potential concurrent write
accesses from userspace. The write operation requires an SPI write, then
toggling of a GPIO, so the lock aims to protect the sanity of the entire
sequence of operation.
This is part of a bigger cleanup.
Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200916092535.76527-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock. The lock protects against potential races when
reading the CR reg and then updating, so that the state of pm_runtime
is consistent between the two operations.
This is part of a bigger cleanup.
Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Link: https://lore.kernel.org/r/20200916092349.75647-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Here are a number of Staging and IIO driver fixes for 5.9-rc5.
The majority of these are IIO driver fixes, to resolve a timestamp issue
that was recently found to affect a bunch of IIO drivers.
The other fixes in here are:
- small IIO driver fixes
- greybus driver fix
- counter driver fix (came in through the IIO fixes tree)
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCX13YsQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yk/2ACgwHmZh89xVW6VujiPJXNiBtLmrQAAoNbDaO45
+zODfdFDsPWhXBeQIINO
=AxzP
-----END PGP SIGNATURE-----
Merge tag 'staging-5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging/IIO driver fixes from Greg KH:
"Here are a number of staging and IIO driver fixes for 5.9-rc5.
The majority of these are IIO driver fixes, to resolve a timestamp
issue that was recently found to affect a bunch of IIO drivers.
The other fixes in here are:
- small IIO driver fixes
- greybus driver fix
- counter driver fix (came in through the IIO fixes tree)
All of these have been in linux-next for a while with no reported
issues"
* tag 'staging-5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (23 commits)
iio: adc: mcp3422: fix locking on error path
iio: adc: mcp3422: fix locking scope
iio: adc: meson-saradc: Use the parent device to look up the calib data
iio:adc:max1118 Fix alignment of timestamp and data leak issues
iio:adc:ina2xx Fix timestamp alignment issue.
iio:adc:ti-adc084s021 Fix alignment and data leak issues.
iio:adc:ti-adc081c Fix alignment and data leak issues
iio:magnetometer:ak8975 Fix alignment and data leak issues.
iio:light:ltr501 Fix timestamp alignment issue.
iio:light:max44000 Fix timestamp alignment and prevent data leak.
iio:chemical:ccs811: Fix timestamp alignment and prevent data leak.
iio:proximity:mb1232: Fix timestamp alignment and prevent data leak.
iio:accel:mma7455: Fix timestamp alignment and prevent data leak.
iio:accel:bmc150-accel: Fix timestamp alignment and prevent data leak.
iio:accel:mma8452: Fix timestamp alignment and prevent data leak.
iio: accel: kxsd9: Fix alignment of local buffer.
iio: adc: rockchip_saradc: select IIO_TRIGGERED_BUFFER
iio: adc: ti-ads1015: fix conversion when CONFIG_PM is not set
counter: microchip-tcb-capture: check the correct variable
iio: cros_ec: Set Gyroscope default frequency to 25Hz
...
Extend support to read/write byte data from/to the device using
debugfs iio interface.
Signed-off-by: Nishant Malpani <nish.malpani25@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200910180450.29696-4-nish.malpani25@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Provide a way for continuous data capture by setting up buffer support. The
data ready signal exposed at the SYNC pin of the ADXRS290 is exploited as
a hardware interrupt which triggers to fill the buffer.
Triggered buffer setup was tested with both hardware trigger (DATA_RDY) and
software triggers (sysfs-trig & hrtimer).
Signed-off-by: Nishant Malpani <nish.malpani25@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200910180450.29696-2-nish.malpani25@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Make use of devm_add_action_or_reset() hook to switch device into STANDBY
mode during standard resource unwinding. The patch includes a helper
function, in the form of adxrs290_set_mode(), to realise driving the
device into STANDBY mode.
Signed-off-by: Nishant Malpani <nish.malpani25@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200910122711.16670-1-nish.malpani25@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Conversion of error paths to dev_err_probe() dropped one return
statement. The driver will continue to probe if getting booster
regulator fails.
Fixes: ce30eeb613 ("iio: adc: stm32: Simplify with dev_err_probe()")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/1599727927-7776-1-git-send-email-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
We found some sensors which are much slower (20% at room temperature)
than nominal. According to the data sheet, up to 27% is possible. Now I
add 33% to the nominal time out, hopefully this is enough.
Signed-off-by: Christian Eggers <ceggers@arri.de>
Link: https://lore.kernel.org/r/20200909154439.10308-1-ceggers@arri.de
Fixes: 403e5586b5 ("iio: light: as73211: New driver")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Since object temperature might be different than the sensor temperature
the infrared sensors should provide an interface to inject ambient
temperature. This was in past done via write to ambient temperature
interface (in_temp_ambient_raw), but I think most people did not know
about it. This solution introduces a new iio type of the CALIBAMBIENT
which is hopefully more descriptive and more explicit about the purpose
and capabilities of the sensors.
Signed-off-by: Crt Mori <cmo@melexis.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200906210231.383976-1-cmo@melexis.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use the managed variant of krealloc() and shrink the code a bit.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20200824173859.4910-4-brgl@bgdev.pl
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On one board I found that:
probe of 5-0028 returned 1 after 259547 usecs
While some of this time is attributable to the pile of i2c transfers
that we do at probe time, the lion's share (over 200 ms) is sitting
waiting in the polling loop in sx9310_init_compensation() waiting for
the hardware to indicate that it's done.
There's no reason to block probe of all other devices on our probe.
Turn on async probe.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Daniel Campello <campello@chromium.org>
Link: https://lore.kernel.org/r/20200901081920.v2.1.Id02b2f451b3eed71ddd580f4b8b44b3e33e84970@changeid
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There seems no reason to allow for compile-testing on ARM only, so
remove this restriction.
Build-tested with allyesconfig on x86.
Signed-off-by: Alex Dewar <alex.dewar90@gmail.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20200904170416.16061-1-alex.dewar90@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There are few blank lines that split structure definitions
with their users. Remove them to increase readability.
While here, update copyright year.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200831090813.78841-8-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The driver is quite likely used only on ACPI based platforms and
rarely build with CONFIG_ACPI=n. Even though, the few dozens of bytes
is better than ugly ifdeffery and inclusion of heavy header.
As a result, replace acpi.h with mod_devicetable.h.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200831090813.78841-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Convert to use ->read_avail() instead of open-coded attribute handling.
While here, fix the typo in array definition and append comma in case of
the future extension.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200831090813.78841-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Potentially bma220_init() and bma220_deinit() may return positive codes.
Fix the logic to return proper error codes instead.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200831090813.78841-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
A transfer may fall shorter than the bytes in the block.
This information is available in the residue from the DMA engine, so we can
compute actual `bytes_used` with that by subtracting the residue.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20200826052011.13348-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
By default, if all three channels (x, y, z) are enabled, sample sets of
concurrent 3-axis data is stored in the FIFO. This patch adds the option
to configure the FIFO to store peak acceleration (x, y and z) of every
over-threshold event. When pushing to iio buffer we push only enabled
axis data.
Currently the driver configures adxl372 to work in loop mode.
The inactivity and activity timings decide how fast the chip
will loop through the awake and waiting states and the
thresholds on x,y,z axis decide when activity or inactivity
will be detected.
This patch adds standard events sysfs entries for the inactivity
and activity timings: thresh_falling_period/thresh_rising_period
and for the in_accel_x_thresh_falling/rising_value.
Signed-off-by: Stefan Popa <stefan.popa@analog.com>
Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Link: https://lore.kernel.org/r/20200810093257.65929-2-alexandru.tachici@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is some inconsistency and whitespace cleanup performed in this
patch. It was done on top of my other patches, but I can rebase to head
of the togreg branch if it would go in sooner.
Signed-off-by: Crt Mori <cmo@melexis.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200818213737.140613-6-cmo@melexis.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
For some time the market wants medical grade accuracy in medical range,
while still retaining the declared accuracy outside of the medical range
within the same sensor. That is why we created extended calibration
which is automatically switched to when object temperature is too high.
This patch also introduces the object_ambient_temperature variable which
is needed for more accurate calculation of the object infra-red
footprint as sensor's ambient temperature might be totally different
than what the ambient temperature is at object and that is why we can
have some more errors which can be eliminated. Currently this temperature
is fixed at 25, but the interface to adjust it by user (with external
sensor or just IR measurement of the other object which acts as ambient),
will be introduced in another commit.
Signed-off-by: Crt Mori <cmo@melexis.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200818213737.140613-5-cmo@melexis.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reduce number of lines and improve readability to convert polling while
loops to regmap_read_poll_timeout.
Signed-off-by: Crt Mori <cmo@melexis.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200818213737.140613-4-cmo@melexis.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Document internal/private struct for mlx90632 device.
Signed-off-by: Crt Mori <cmo@melexis.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200818213737.140613-3-cmo@melexis.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
TAdut4 was calculated each iteration although it did not change. In light
of near future additions of the Extended range DSP calculations, this
function refactoring will help reduce unrelated changes in that series as
well as reduce the number of new functions needed.
Signed-off-by: Crt Mori <cmo@melexis.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200818213737.140613-2-cmo@melexis.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Insert a missing mutex_init() call during the probe that initializes
the driver's local lock to unlocked state.
Fixes: 2c8920fff1 ("iio: gyro: Add driver support for ADXRS290")
Signed-off-by: Nishant Malpani <nish.malpani25@gmail.com>
Link: https://lore.kernel.org/r/20200825124552.11155-1-nish.malpani25@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20200829064726.26268-18-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200829064726.26268-17-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200829064726.26268-16-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200829064726.26268-15-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200829064726.26268-14-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Link: https://lore.kernel.org/r/20200829064726.26268-13-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20200829064726.26268-12-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Link: https://lore.kernel.org/r/20200829064726.26268-11-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200829064726.26268-10-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20200829064726.26268-9-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200829064726.26268-8-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200829064726.26268-7-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20200829064726.26268-6-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200829064726.26268-5-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200829064726.26268-4-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20200829064726.26268-3-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200829064726.26268-2-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200829064726.26268-1-krzk@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for atlas,hum-ezo / humidity sensor which with scaling
provides respective data in millipercent
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use kobj_to_dev() instead of container_of()
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
These are never modified and can be made const to allow the compiler to
put it in read-only memory.
Before:
text data bss dec hex filename
6642 12608 64 19314 4b72 drivers/iio/dac/ad5686.o
After:
text data bss dec hex filename
16946 2304 64 19314 4b72 drivers/iio/dac/ad5686.o
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Whilst fairly unlikely anyone will ever use this driver with anything
other than DT, we are trying to move IIO over to the generic interfaces
where easy to do so.
In this case this involved moving to generic check on presence
of fwnode, generic device_get_match_data() and dropping the of_match_ptr
protection. Also relevant header changes to have property.h and
mod_devicetable.h only.
Also drop the casting away of a const in favour of retaining
the const throughout.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Quentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Update email to author's current employer
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
We have no known users of these in the wild.
it seems very unlikely these are real IDs having the form ADCXXXX
as that ID is owned by Achnor Datacomm not TI.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
I'm trying to clean this (now) anti-pattern out of IIO to avoid
cut and paste into new drivers.
Also add an include of mod_devicetable.h as the driver directly uses
struct of_device_id which is defined in there.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
There is no real advantage in having these protections and
for parts that do not have an explicit ACPI ID, it prevents the
use of PRP0001. I'm trying to clear this out of IIO in general
to avoid copying in new drivers.
Include mod_devicetable.h as we are using of_device_id in here so
including that header is best practice.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Angelo Compagnucci <angelo.compagnucci@gmail.com>
This driver cannot be instantiated from ACPI due to it's use of
syscon_regmap_lookup_by_phandle() but in the interests of clearing
this anti pattern out of IIO, let us switch to an explicit
check in Kconfig and remove the protections on the of_match_table
The switch of header is because we only use of_device_id
in here and that is defined in mod_devicetable.h not of.h.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
The driver currently only allows channel 0 to be powered down but the
multi-channel variants of the hardware allow each channel to be powered
down separately and with separate power down modes. Add support for
this.
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Acked-by: Sean Nyekjaer <sean@geanix.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add driver support for HDC2010/2080 series devices and sysfs
documentation for their heater element.
HDC2010 is an integrated high-accuracy humidity and temperature sensor
with very low power consumption. The device includes a resistive heating
element. The temperature range is -40C to 125C with 0.2C
accuracy. Humidity measurement is 0 to 100% with 2% RH accuracy.
Signed-off-by: Eugene Zaikonnikov <ez@norphonic.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
We shouldn't need to set default irq trigger flags here as the firmware
should have properly indicated the trigger type, i.e. level low, in the
DT or ACPI tables.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Enable the main power supply (vdd) and digital IO power supply (svdd)
during probe so that the i2c communication and device works properly on
boards that aggressively power gate these supplies.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This struct member isn't used. Drop it.
Fixes: 72ad02b15d ("iio: Add SEMTECH SX9310/9311 sensor driver")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Daniel Campello <campello@chromium.org>
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Miscellaneous format fixes throughout the whole file.
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Improves readability by storing &client->dev in a local variable.
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Checks for non-zero return values to signal error conditions.
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Simplify compensation stage by using regmap_read_poll_timeout().
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Uses for_each_set_bit() macro to loop over channel bitmaps.
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Makes use __aligned(8) to ensure that the timestamp is correctly aligned
when we call io_push_to_buffers_with_timestamp().
Also makes use of sizeof() for regmap_bulk_read instead of static value.
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Uses .probe_new in place of .probe. Also uses device_get_match_data()
for whoami matching.
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Avoids unused warnings due to acpi/of table macros.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fixes enable/disable irq handling at various points. The driver needs to
only enable/disable irqs if there is an actual irq handler installed.
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Follows spec sheet for macro declarations.
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Support for AMS AS73211 JENCOLOR(R) Digital XYZ Sensor.
This driver has no built-in trigger. In order for making triggered
measurements, an external (software) trigger driver like
iio-trig-hrtimer or iio-trig-sysfs is required.
The sensor supports single and continuous measurement modes. The latter
is not used by design as this would require tight timing synchronization
between hardware and driver without much benefit.
Datasheet: https://ams.com/documents/20143/36005/AS73211_DS000556_3-01.pdf
Signed-off-by: Christian Eggers <ceggers@arri.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reading from the chip should be unlocked on error path else the lock
could never being released.
Fixes: 07914c84ba ("iio: adc: Add driver for Microchip MCP3422/3/4 high resolution ADC")
Fixes: 3f1093d83d ("iio: adc: mcp3422: fix locking scope")
Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Link: https://lore.kernel.org/r/20200901093218.1500845-1-angelo.compagnucci@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Locking should be held for the entire reading sequence involving setting
the channel, waiting for the channel switch and reading from the
channel.
If not, reading from a channel can result mixing with the reading from
another channel.
Fixes: 07914c84ba ("iio: adc: Add driver for Microchip MCP3422/3/4 high resolution ADC")
Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Link: https://lore.kernel.org/r/20200819075525.1395248-1-angelo.compagnucci@gmail.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
On the older-gen 32-bit SoCs the meson-saradc driver is used to read the
SoC temperature. This requires reading calibration data from the eFuse.
Looking up the calibration data nvmem-cell requires the OF device_node
pointer to be available in the struct device which is passed to
devm_nvmem_cell_get(). This however got lost with commit 8cb631ccbb
("iio: Remove superfluous of_node assignments") from indio_dev->dev. As
devm_nvmem_cell_get() is called in the initialization phase the
device_node is not yet available because the NVMEM cell is looked up
before iio_device_register() is called (which would then set the
device_node automatically).
Use the parent device to look up the NVMEM cell instead to fix this
issue.
Fixes: 8cb631ccbb ("iio: Remove superfluous of_node assignments")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data.
This data is allocated with kzalloc so no data can leak apart
from previous readings.
The explicit alignment of ts is necessary to ensure correct padding
on architectures where s64 is only 4 bytes aligned such as x86_32.
Fixes: a9e9c7153e ("iio: adc: add max1117/max1118/max1119 ADC driver")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses a 32 byte array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc so no
data can leak apart from previous readings. The explicit alignment
isn't technically needed here, but it reduced fragility and avoids
cut and paste into drivers where it will be needed.
If we want this in older stables will need manual backport due to
driver reworks.
Fixes: c43a102e67 ("iio: ina2xx: add support for TI INA2xx Power Monitors")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Cc: Marc Titinger <mtitinger@baylibre.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv().
This data is allocated with kzalloc so no data can leak apart from
previous readings.
The force alignment of ts is not strictly necessary in this case
but reduces the fragility of the code.
Fixes: 3691e5a694 ("iio: adc: add driver for the ti-adc084s021 chip")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Mårten Lindahl <martenli@axis.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv().
This data is allocated with kzalloc so no data can leak apart
from previous readings.
The eplicit alignment of ts is necessary to ensure correct padding
on x86_32 where s64 is only aligned to 4 bytes.
Fixes: 08e05d1fce ("ti-adc081c: Initial triggered buffer support")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
After the replacement of the /* fall through */ comment with the
fallthrough pseudo-keyword macro, the natural reading of a code
comment was broken.
Fix the natural reading of such a comment and make it intelligible.
Reported-by: Peter Rosin <peda@axentia.se>
Acked-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
A follow-up patch will extend the number of errors reported by
cros_ec_cmd_xfer_status(). Specifically, the function will return
-EOPNOTSUPP if a command is not supported by the EC. Prepare for it.
Cc: Gwendal Grignou <gwendal@chromium.org>
Cc: Yu-Hsuan Hsu <yuhsuan@chromium.org>
Cc: Prashant Malani <pmalani@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data.
This data is allocated with kzalloc so no data can leak apart from
previous readings.
The explicit alignment of ts is not necessary in this case as by
coincidence the padding will end up the same, however I consider
it to make the code less fragile and have included it.
Fixes: bc11ca4a0b ("iio:magnetometer:ak8975: triggered buffer support")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Gregor Boirie <gregor.boirie@parrot.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
Here we use a structure on the stack. The driver already did an
explicit memset so no data leak was possible.
Forced alignment of ts is not strictly necessary but probably makes
the code slightly less fragile.
Note there has been some rework in this driver of the years, so no
way this will apply cleanly all the way back.
Fixes: 2690be9051 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses a 16 byte array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv().
This data is allocated with kzalloc so no data can leak appart
from previous readings.
It is necessary to force the alignment of ts to avoid the padding
on x86_32 being different from 64 bit platorms (it alows for
4 bytes aligned 8 byte types.
Fixes: 06ad7ea10e ("max44000: Initial triggered buffer support")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc so no
data can leak appart from previous readings.
The explicit alignment of ts is necessary to ensure consistent
padding for x86_32 in which the ts would otherwise be 4 byte aligned.
Fixes: 283d26917a ("iio: chemical: ccs811: Add triggered buffer support")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Narcisa Ana Maria Vasile <narcisaanamaria12@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses a 16 byte s16 array on the stack As Lars also noted
this anti pattern can involve a leak of data to userspace and that
indeed can happen here. We close both issues by moving to
a suitable structure in the iio_priv() data with alignment
ensured by use of an explicit c structure. This data is allocated
with kzalloc so no data can leak appart from previous readings.
In this case the forced alignment of the ts is necessary to ensure
correct padding on x86_32 where the s64 would only be 4 byte aligned.
Fixes: 16b0526153 ("mb1232.c: add distance iio sensor with i2c")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Andreas Klinger <ak@it-klinger.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: <Stable@vger.kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses a 16 byte u8 array on the stack As Lars also noted
this anti pattern can involve a leak of data to userspace and that
indeed can happen here. We close both issues by moving to
a suitable structure in the iio_priv() data with alignment
ensured by use of an explicit c structure. This data is allocated
with kzalloc so no data can leak appart from previous readings.
The force alignment of ts is not strictly necessary in this particularly
case but does make the code less fragile.
Fixes: a84ef0d181 ("iio: accel: add Freescale MMA7455L/MMA7456L 3-axis accelerometer driver")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: <Stable@vger.kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses a 16 byte array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by moving
to a suitable structure in the iio_priv() data with alignment
ensured by use of an explicit c structure. This data is allocated
with kzalloc so no data can leak appart from previous readings.
Fixes tag is beyond some major refactoring so likely manual backporting
would be needed to get that far back.
Whilst the force alignment of the ts is not strictly necessary, it
does make the code less fragile.
Fixes: 3bbec97733 ("iio: bmc150_accel: add support for hardware fifo")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses a 16 byte u8 array on the stack. As Lars also noted
this anti pattern can involve a leak of data to userspace and that
indeed can happen here. We close both issues by moving to
a suitable structure in the iio_priv() data with alignment
ensured by use of an explicit c structure. This data is allocated
with kzalloc so no data can leak appart from previous readings.
The additional forcing of the 8 byte alignment of the timestamp
is not strictly necessary but makes the code less fragile by
making this explicit.
Fixes: c7eeea93ac ("iio: Add Freescale MMA8452Q 3-axis accelerometer driver")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
iio_push_to_buffers_with_timestamp assumes 8 byte alignment which
is not guaranteed by an array of smaller elements.
Note that whilst in this particular case the alignment forcing
of the ts element is not strictly necessary it acts as good
documentation. Doing this where not necessary should cut
down on the number of cut and paste introduced errors elsewhere.
Fixes: 0427a106a9 ("iio: accel: kxsd9: Add triggered buffer handling")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
The kernel fails to compile due to undefined reference to
devm_iio_triggered_buffer_setup() if IIO_TRIGGERED_BUFFER is not
enabled. The original patch [1] had this dependency. But somehow it
didn't make it into the kernel tree. Re-add it.
[1] https://lore.kernel.org/lkml/20200623233011.2319035-3-heiko@sntech.de/
Fixes: 4e130dc7b4 ("iio: adc: rockchip_saradc: Add support iio buffers")
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To stop conversion ads1015_set_power_state() function call unimplemented
function __pm_runtime_suspend() from pm_runtime_put_autosuspend()
if CONFIG_PM is not set.
In case of CONFIG_PM is not set: __pm_runtime_suspend() returns -ENOSYS,
so ads1015_read_raw() failed because ads1015_set_power_state() returns an
error.
If CONFIG_PM is disabled, there is no need to start/stop conversion.
Fix it by adding return 0 function variant if CONFIG_PM is not set.
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
Fixes: ecc24e72f4 ("iio: adc: Add TI ADS1015 ADC driver support")
Tested-by: Maxim Kiselev <bigunclemax@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
BMI160 Minimium gyroscope frequency in normal mode is 25Hz.
When older EC firmware do not report their sensors frequencies,
use 25Hz as the minimum for gyroscope to be sure it works on BMI160.
Fixes: ae7b02ad2f ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs")
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
ADXRS290 is a high performance MEMS pitch and roll (dual-axis in-plane)
angular rate sensor (gyroscope) designed for use in stabilization
applications. It also features an internal temperature sensor and
programmable high-pass and low-pass filters.
Add support for ADXRS290 in direct-access mode for now.
Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ADXRS290.pdf
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Nishant Malpani <nish.malpani25@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Make sure that the trigger function stubs are all static inline.
Otherwise we might see compiler warnings about declared but unused
functions.
Fixes 77712e5fbe: ("Staging: iio: Staticise non-exported functions")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The change is mostly cosmetic. When looking into the menuconfig help of the
ad8366 driver, the HMC1119 chip should also show up (since the driver
supports it).
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The driver does not have a struct of_device_id table, but supported
devices are registered via Device Trees. This patch adds OF device ID
table.
Signed-off-by: Stefan Popa <stefan.popa@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The change is mostly stylistic. The table should be indented with tabs
instead of spaces.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The driver pretty much uses device managed functions. The only left-over is
the iio_device_register() function, which also requires an action-or-reset
hook to disable the regulator on the remove and error path.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for the Atlas EZO O2 chemical sensor which required
some refactoring of the driver and parsing of i2c transfer.
Sensor data is converted by the scaling value from percent to
IIO_CONCENTRATION.
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add modifier IIO_MOD_O2 for O2 concentration reporting
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reset hw time samples generator after system resume in order to avoid
disalignment between system and device time reference since FIFO
batching and time samples generator are disabled during suspend.
Fixes: 213451076b ("iio: imu: st_lsm6dsx: add hw timestamp support")
Tested-by: Sean Nyekjaer <sean@geanix.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There are 2 exit paths where the lock isn't held, but try to unlock the
mutex when exiting. In these places we should just return from the
function.
A neater approach would be to cleanup the ad5592r_read_raw(), but that
would make this patch more difficult to backport to stable versions.
Fixes 56ca9db862: ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs")
Reported-by: Charles Stanhope <charles.stanhope@gmail.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This was introduced initially via commit 78289b4a58 ("iio: core: pass
parent device as parameter during allocation"), but was accidentally
removed via commit 6d4ebd565d ("iio: core: wrap IIO device into an
iio_dev_opaque object").
This looks like a rebase gone wrong, and ends up breaking devicetree
bindings of IIO clients.
This change adds back the parent assignment.
Fixes 6d4ebd565d: ("iio: core: wrap IIO device into an iio_dev_opaque object")
Reported-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Tested-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change does the following:
* removes the SPI device table in favor of the OF device table
* adds 'name' && 'chip_id' fields to chip_info
* implements chip ID & silicon revision checking; the device ID for
AD7124-4 is 0x0, so just checking that value can be useless;
but at least the silicon revision isn't 0, so a non-zero value can be
used to check that "a" device is on the SPI bus; it's probably the best
way to narrow it down to one of the 2 AD7124 chip IDs
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The SADC component in JZ47xx SoCs provides support for touchscreen
operations (pen position and pen down pressure) in single-ended and
differential modes.
The touchscreen component of SADC takes a significant time to stabilize
after first receiving the clock and a delay of 50ms has been empirically
proven to be a safe value before data sampling can begin.
Of the known hardware to use this controller, GCW Zero and Anbernic RG-350
utilize the touchscreen mode by having their joystick(s) attached to the
X/Y positive/negative input pins.
JZ4770 and later SoCs introduce a low-level command feature. With it, up
to 32 commands can be programmed, each one corresponding to a sampling
job. It allows to change the low-voltage reference, the high-voltage
reference, have them connected to VCC, GND, or one of the X-/X+ or Y-/Y+
pins.
This patch introduces support for 6 stream-capable channels:
- channel #0 samples X+/GND
- channel #1 samples Y+/GND
- channel #2 samples X-/GND
- channel #3 samples Y-/GND
- channel #4 samples X+/X-
- channel #5 samples Y+/Y-
Being able to sample X-/GND and Y-/GND is useful on some devices, where
one joystick is connected to the X+/Y+ pins, and a second joystick is
connected to the X-/Y- pins.
All the boards which probe this driver have the interrupt provided from
Device Tree, with no need to handle a case where the IRQ was not provided.
Co-developed-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Artur Rojek <contact@artur-rojek.eu>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Instead of having one array of struct iio_chan_spec for all SoCs, and
have some SoCs remove the last item of the array as they can't use it,
have each SoC define its array of supported channels.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Tested-by: Artur Rojek <contact@artur-rojek.eu>
Signed-off-by: Artur Rojek <contact@artur-rojek.eu>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Provide an of_xlate callback in order to retrieve the correct channel
specifier index from the IIO channels array.
Signed-off-by: Artur Rojek <contact@artur-rojek.eu>
Tested-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Introduce error checks for the clk_enable calls used in this driver.
As part of the changes, move clk_enable/clk_disable calls out of
ingenic_adc_set_config and into respective logic of its callers.
Signed-off-by: Artur Rojek <contact@artur-rojek.eu>
Tested-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The STK3311 chip has a variant called STK3311-X, which has a different
chip id of 0x12.
Add the chip id to the driver.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Ondrej Jirman <megous@megous.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The change is more cosmetic. There is no need to reference this table in
the probe function since 'of_device_get_match_data' is used, which obtains
this information from the driver object.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This is the only use of kerneldoc in the source file and no
descriptions are provided.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/rockchip_saradc.c:190: warning: Function parameter or member 'reset' not described in 'rockchip_saradc_reset_controller'
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
It doesn't make sense to move it into '*core*' as it's co-located with
other, similar definitions which are used in multiple locations.
Fixes the following W=1 kernel build warning(s):
In file included from drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c:17:
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h:497:44: warning: ‘st_lsm6dsx_accel_ext_info’ defined but not used [-Wunused-const-variable=]
497 | static const struct iio_chan_spec_ext_info st_lsm6dsx_accel_ext_info[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_spi.c:17:
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h:497:44: warning: ‘st_lsm6dsx_accel_ext_info’ defined but not used [-Wunused-const-variable=]
497 | static const struct iio_chan_spec_ext_info st_lsm6dsx_accel_ext_info[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i3c.c:16:
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h:497:44: warning: ‘st_lsm6dsx_accel_ext_info’ defined but not used [-Wunused-const-variable=]
497 | static const struct iio_chan_spec_ext_info st_lsm6dsx_accel_ext_info[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~
Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
No attempt has been made to document any of the demoted functions here.
Fixes the following W=1 kernel build warning(s):
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:174: warning: Function parameter or member 'hw' not described in 'st_lsm6dsx_shub_read_output'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:174: warning: Function parameter or member 'data' not described in 'st_lsm6dsx_shub_read_output'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:174: warning: Function parameter or member 'len' not described in 'st_lsm6dsx_shub_read_output'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:205: warning: Function parameter or member 'hw' not described in 'st_lsm6dsx_shub_write_reg'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:205: warning: Function parameter or member 'addr' not described in 'st_lsm6dsx_shub_write_reg'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:205: warning: Function parameter or member 'data' not described in 'st_lsm6dsx_shub_write_reg'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:205: warning: Function parameter or member 'len' not described in 'st_lsm6dsx_shub_write_reg'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:285: warning: Function parameter or member 'sensor' not described in 'st_lsm6dsx_shub_read'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:285: warning: Function parameter or member 'addr' not described in 'st_lsm6dsx_shub_read'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:285: warning: Function parameter or member 'data' not described in 'st_lsm6dsx_shub_read'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:285: warning: Function parameter or member 'len' not described in 'st_lsm6dsx_shub_read'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:335: warning: Function parameter or member 'sensor' not described in 'st_lsm6dsx_shub_write'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:335: warning: Function parameter or member 'addr' not described in 'st_lsm6dsx_shub_write'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:335: warning: Function parameter or member 'data' not described in 'st_lsm6dsx_shub_write'
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:335: warning: Function parameter or member 'len' not described in 'st_lsm6dsx_shub_write'
Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fixes the following W=1 kernel build warning(s):
drivers/iio/magnetometer/ak8974.c:200: warning: Function parameter or member 'scan' not described in 'ak8974'
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Samu Onkalo <samu.p.onkalo@nokia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Kerneldoc is only suitable for documenting functions and struct/enums.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/qcom-pm8xxx-xoadc.c:133: warning: Excess function parameter 'PM8XXX_CHANNEL_INTERNAL' description in 'PM8XXX_CHANNEL_INTERNAL'
drivers/iio/adc/qcom-pm8xxx-xoadc.c:133: warning: Excess function parameter 'PM8XXX_CHANNEL_125V' description in 'PM8XXX_CHANNEL_INTERNAL'
drivers/iio/adc/qcom-pm8xxx-xoadc.c:133: warning: Excess function parameter 'PM8XXX_CHANNEL_INTERNAL_2' description in 'PM8XXX_CHANNEL_INTERNAL'
drivers/iio/adc/qcom-pm8xxx-xoadc.c:133: warning: Excess function parameter 'PM8XXX_CHANNEL_MUXOFF' description in 'PM8XXX_CHANNEL_INTERNAL'
drivers/iio/adc/qcom-pm8xxx-xoadc.c:412: warning: Function parameter or member 'variant' not described in 'pm8xxx_xoadc'
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-msm@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This is the only use of kerneldoc in the source file and no
descriptions are provided.
Fixes the following W=1 kernel build warning(s):
drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c:118: warning: Function parameter or member 'irq' not described in 'inv_mpu6050_read_fifo'
drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c:118: warning: Function parameter or member 'p' not described in 'inv_mpu6050_read_fifo'
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
No attempt has been made to document any of the demoted functions here.
Fixes the following W=1 kernel build warning(s):
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:444: warning: Function parameter or member 'st' not described in 'inv_mpu6050_set_lpf_regs'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:444: warning: Function parameter or member 'val' not described in 'inv_mpu6050_set_lpf_regs'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:480: warning: Function parameter or member 'indio_dev' not described in 'inv_mpu6050_init_config'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:862: warning: Function parameter or member 'st' not described in 'inv_mpu6050_set_lpf'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:862: warning: Function parameter or member 'rate' not described in 'inv_mpu6050_set_lpf'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:893: warning: Function parameter or member 'dev' not described in 'inv_mpu6050_fifo_rate_store'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:893: warning: Function parameter or member 'attr' not described in 'inv_mpu6050_fifo_rate_store'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:893: warning: Function parameter or member 'buf' not described in 'inv_mpu6050_fifo_rate_store'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:893: warning: Function parameter or member 'count' not described in 'inv_mpu6050_fifo_rate_store'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:954: warning: Function parameter or member 'dev' not described in 'inv_fifo_rate_show'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:954: warning: Function parameter or member 'attr' not described in 'inv_fifo_rate_show'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:954: warning: Function parameter or member 'buf' not described in 'inv_fifo_rate_show'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:975: warning: Function parameter or member 'dev' not described in 'inv_attr_show'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:975: warning: Function parameter or member 'attr' not described in 'inv_attr_show'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:975: warning: Function parameter or member 'buf' not described in 'inv_attr_show'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:1282: warning: Function parameter or member 'st' not described in 'inv_check_and_setup_chip'
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Very few of the struct attributes have been documented here.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'dev' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'palmas' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'irq' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'irq_auto_0' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'irq_auto_1' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'adc_info' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'conv_completion' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'wakeup1_data' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'wakeup2_data' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'wakeup1_enable' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member 'wakeup2_enable' not described in 'palmas_gpadc'
Cc: Pradeep Goudagunta <pgoudagunta@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
No attempt has been made to document any of the demoted structs here.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/max9611.c:117: warning: cannot understand function prototype: 'const unsigned int max9611_mux_conf[][2] = '
drivers/iio/adc/max9611.c:145: warning: cannot understand function prototype: 'const unsigned int max9611_gain_conf[][2] = '
Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Kerneldoc expects attributes/parameters to be in '@*.: ' format.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/max1363.c:190: warning: Function parameter or member 'lock' not described in 'max1363_state'
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Rohit Sarkar <rohitsarkar5398@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fixes the following W=1 kernel build warning(s):
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h:487:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h:497:44: warning: ‘st_lsm6dsx_accel_ext_info’ defined but not used [-Wunused-const-variable=]
Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
'fxas21002c_reg_fields' is only used in '*core*', meaning that '*i2c*'
and '*spi*' complain of a defined but not used const variable. Let's
move it into the source file.
Fixes the following W=1 kernel build warning(s):
In file included from drivers/iio/gyro/fxas21002c_i2c.c:14:
drivers/iio/gyro/fxas21002c.h:79:31: warning: ‘fxas21002c_reg_fields’ defined but not used [-Wunused-const-variable=]
79 | static const struct reg_field fxas21002c_reg_fields[] = {
| ^~~~~~~~~~~~~~~~~~~~~
In file included from drivers/iio/gyro/fxas21002c_spi.c:14:
drivers/iio/gyro/fxas21002c.h:79:31: warning: ‘fxas21002c_reg_fields’ defined but not used [-Wunused-const-variable=]
79 | static const struct reg_field fxas21002c_reg_fields[] = {
| ^~~~~~~~~~~~~~~~~~~~~
Cc: Rui Miguel Silva <rmfrfs@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fixes the following W=1 kernel build warning(s):
drivers/iio/accel/sca3000.c:210: warning: Function parameter or member 'mot_det_mult_xz' not described in 'sca3000_chip_info'
drivers/iio/accel/sca3000.c:210: warning: Function parameter or member 'mot_det_mult_y' not described in 'sca3000_chip_info'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'indio_dev' not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'chan' not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'type' not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'dir' not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'info' not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'val' not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'val2' not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:1110: warning: Function parameter or member 'indio_dev' not described in 'sca3000_read_event_config'
drivers/iio/accel/sca3000.c:1110: warning: Function parameter or member 'chan' not described in 'sca3000_read_event_config'
drivers/iio/accel/sca3000.c:1110: warning: Function parameter or member 'type' not described in 'sca3000_read_event_config'
drivers/iio/accel/sca3000.c:1110: warning: Function parameter or member 'dir' not described in 'sca3000_read_event_config'
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
None of the headers demoted here provide any descriptions.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/cpcap-adc.c💯 warning: Function parameter or member 'ato_in' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c💯 warning: Function parameter or member 'atox_in' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c💯 warning: Function parameter or member 'adc_ps_factor_in' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c💯 warning: Function parameter or member 'atox_ps_factor_in' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c💯 warning: Function parameter or member 'ato_out' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c💯 warning: Function parameter or member 'atox_out' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c💯 warning: Function parameter or member 'adc_ps_factor_out' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c💯 warning: Function parameter or member 'atox_ps_factor_out' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_AD0' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BATTP' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_VBUS' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_AD3' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BPLUS_AD4' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_CHG_ISENSE' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BATTI' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_USB_ID' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_AD8' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_AD9' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_LICELL' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_HV_BATTP' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_TSX1_AD12' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_TSX2_AD13' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_TSY1_AD14' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_TSY2_AD15' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BATTP_PI16' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BATTI_PI17' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_CHANNEL_NUM' not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:165: warning: Enum value 'CPCAP_ADC_TIMING_IMM' not described in enum 'cpcap_adc_timing'
drivers/iio/adc/cpcap-adc.c:165: warning: Enum value 'CPCAP_ADC_TIMING_IN' not described in enum 'cpcap_adc_timing'
drivers/iio/adc/cpcap-adc.c:165: warning: Enum value 'CPCAP_ADC_TIMING_OUT' not described in enum 'cpcap_adc_timing'
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
All lines should start with ' *'.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/at91_adc.c:160: warning: bad line: (Interruptions registers mostly)
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Kerneldoc expects attributes/parameters to be in '@*.: ' format.
Fixes the following W=1 kernel build warning(s):
drivers/iio/dac/ad5504.c:58: warning: Function parameter or member 'pwr_down_mask' not described in 'ad5504_state'
drivers/iio/dac/ad5504.c:58: warning: Function parameter or member 'pwr_down_mode' not described in 'ad5504_state'
drivers/iio/dac/ad5504.c:64: warning: cannot understand function prototype: 'enum ad5504_supported_device_ids '
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This is the only use of function related kerneldoc in the sourcefile
and no descriptions are provided.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/ad799x.c:192: warning: Function parameter or member 'irq' not described in 'ad799x_trigger_handler'
drivers/iio/adc/ad799x.c:192: warning: Function parameter or member 'p' not described in 'ad799x_trigger_handler'
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Kerneldoc expects attributes/parameters to be in '@*.: ' format.
Fixes the following W=1 kernel build warning(s):
drivers/iio/light/us5182d.c:457: warning: Function parameter or member 'data' not described in 'us5182d_update_dark_th'
drivers/iio/light/us5182d.c:457: warning: Function parameter or member 'index' not described in 'us5182d_update_dark_th'
drivers/iio/light/us5182d.c:479: warning: Function parameter or member 'data' not described in 'us5182d_apply_scale'
drivers/iio/light/us5182d.c:479: warning: Function parameter or member 'index' not described in 'us5182d_apply_scale'
Cc: Adriana Reus <adriana.reus@intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
'*'s are not welcome in kerneldoc parameter names.
Fixes the following W=1 kernel build warning(s):
drivers/iio/temperature/mlx90632.c:175: warning: Function parameter or member 'data' not described in 'mlx90632_perform_measurement'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Crt Mori <cmo@melexis.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
No attempt has been made to document any of the demoted functions here
Fixes the following W=1 kernel build warning(s):
drivers/iio/light/si1145.c:192: warning: Function parameter or member 'data' not described in '__si1145_command_reset'
drivers/iio/light/si1145.c:228: warning: Function parameter or member 'data' not described in 'si1145_command'
drivers/iio/light/si1145.c:228: warning: Function parameter or member 'cmd' not described in 'si1145_command'
drivers/iio/light/si1145.c:1186: warning: Function parameter or member 'trig' not described in 'si1145_trigger_set_state'
drivers/iio/light/si1145.c:1186: warning: Function parameter or member 'state' not described in 'si1145_trigger_set_state'
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Dan Leonard <leonard.crestez@intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Kerneldoc expects attributes/parameters to be in '@*.: ' format.
Fixes the following W=1 kernel build warning(s):
drivers/iio/dac/ltc2632.c:50: warning: Function parameter or member 'powerdown_cache_mask' not described in 'ltc2632_state'
drivers/iio/dac/ltc2632.c:50: warning: Function parameter or member 'vref_mv' not described in 'ltc2632_state'
drivers/iio/dac/ltc2632.c:50: warning: Function parameter or member 'vref_reg' not described in 'ltc2632_state'
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Silvan Murer <silvan.murer@gmail.com>
Cc: Maxime Roussin-Belanger <maxime.roussinbelanger@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Kerneldoc expects attributes/parameters to be in '@*.: ' format.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/twl6030-gpadc.c:110: warning: Function parameter or member 'ideal' not described in 'twl6030_gpadc_platform_data'
drivers/iio/adc/twl6030-gpadc.c:110: warning: Function parameter or member 'channel_to_reg' not described in 'twl6030_gpadc_platform_data'
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Nishant Kamat <nskamat@ti.com>
Cc: Balaji T K <balajitk@ti.com>
Cc: Graeme Gregory <gg@slimlogic.co.uk>
Cc: Girish S Ghongdemath <girishsg@ti.com>
Cc: Ambresh K <ambresh@ti.com>
Cc: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
Cc: Mikko Ylinen <mikko.k.ylinen@nokia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
