OSDN Git Service
Gwendal Grignou [Tue, 9 Mar 2021 19:36:17 +0000 (11:36 -0800)]
iio: lmp91000: Remove code to set trigger parent
iio_trigger_set_drvdata() sets the trigger device parent to first
argument of viio_trigger_alloc(), no need to do it again in the driver
code.
Given data->dev is dev, and we call devm_iio_trigger_alloc with
dev instead of data->dev, we do not have to set data->trig->dev.parent to
dev anymore.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20210309193620.2176163-6-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Gwendal Grignou [Tue, 9 Mar 2021 19:36:16 +0000 (11:36 -0800)]
iio: gp2ap020a00f: Remove code to set trigger parent
iio_trigger_set_drvdata() sets the trigger device parent to first
argument of viio_trigger_alloc(), no need to do it again in the driver
code.
Given data->client is client, and we call devm_iio_trigger_alloc() with
&client->dev, we do not have to set data->trig->dev.parent to
&data->client->dev anymore.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210309193620.2176163-5-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Gwendal Grignou [Tue, 9 Mar 2021 19:36:15 +0000 (11:36 -0800)]
iio: adis_trigger: Remove code to set trigger parent
iio_trigger_set_drvdata() sets the trigger device parent to first
argument of viio_trigger_alloc(), no need to do it again in the driver
code.
Remove adis_trigger_setup() to match other drivers where setting the
trigger is usually done in the probe() routine.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210309193620.2176163-4-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Gwendal Grignou [Tue, 9 Mar 2021 19:36:14 +0000 (11:36 -0800)]
iio: fix devm_iio_trigger_alloc with parent.cocci
Use cocci semantic patch:
@@
expression trigger, P;
@@
trigger = devm_iio_trigger_alloc(P, ...);
...
- trigger->dev.parent = P;
To remove trigger->dev.parent, since it is set by default.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210309193620.2176163-3-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Gwendal Grignou [Tue, 9 Mar 2021 19:36:13 +0000 (11:36 -0800)]
iio: set default trig->dev.parent
When allocated with [devm_]iio_trigger_alloc(), set trig device parent to
the device the trigger is allocated for by default.
It can always be reassigned in the probe routine.
Change iio_trigger_alloc() API to add the device pointer to be coherent
with devm_iio_trigger_alloc, using similar interface to
iio_device_alloc().
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210309193620.2176163-2-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Tachici [Thu, 11 Mar 2021 09:11:54 +0000 (11:11 +0200)]
iio: adc: ad7124: allow more than 8 channels
Currently AD7124-8 driver cannot use more than 8 IIO channels
because it was assigning the channel configurations bijectively
to channels specified in the device-tree. This is not possible
to do when using more than 8 channels as AD7124-8 has only 8
configuration registers.
To allow the user to use all channels at once the driver
will keep in memory configurations for all channels but
will program only 8 of them at a time on the device.
If multiple channels have the same configuration, only
one configuration register will be used. If there
are more configurations than available registers only
the last 8 used configurations will be allowed to exist
on the device in a LRU fashion.
Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20210311091154.47785-2-alexandru.tachici@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Andy Shevchenko [Fri, 12 Mar 2021 13:49:03 +0000 (15:49 +0200)]
iio: light: gp2ap002: Drop unneeded explicit casting
The unnecessary explicit casting is being used. Drop it for good.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210312134903.4296-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Andy Shevchenko [Fri, 12 Mar 2021 13:47:43 +0000 (15:47 +0200)]
iio: imu: st_lsm6dsx: Drop unneeded explicit castings
In a few places the unnecessary explicit castings are being used.
Drop them for good.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210312134743.4055-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Andy Shevchenko [Fri, 12 Mar 2021 13:45:38 +0000 (15:45 +0200)]
iio: imu: fxos8700: Drop unneeded explicit castings
In a few places the unnecessary explicit castings are being used.
Drop them for good.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210312134538.3759-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Andy Shevchenko [Fri, 12 Mar 2021 13:43:49 +0000 (15:43 +0200)]
iio: chemical: bmp680: Drop unneeded explicit castings
In few places the unnecessary explicit castings are being used.
Drop them for good.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210312134349.3472-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Stephen Boyd [Thu, 11 Feb 2021 02:46:01 +0000 (18:46 -0800)]
iio: proximity: Add a ChromeOS EC MKBP proximity driver
Add support for a ChromeOS EC proximity driver that exposes a "front"
proximity sensor via the IIO subsystem. The EC decides when front
proximity is near and sets an MKBP switch 'EC_MKBP_FRONT_PROXIMITY' to
notify the kernel of proximity. Similarly, when proximity detects
something far away it sets the switch bit to 0. For now this driver
exposes a single sensor, but it could be expanded in the future via more
MKBP bits if desired.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benson Leung <bleung@chromium.org>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20210211024601.1963379-4-swboyd@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Stephen Boyd [Thu, 11 Feb 2021 02:46:00 +0000 (18:46 -0800)]
dt-bindings: iio: Add cros ec proximity yaml doc
Some cros ECs support a front proximity MKBP event via
'EC_MKBP_FRONT_PROXIMITY'. Add a DT binding to document this feature via
a node that is a child of the main cros_ec device node. Devices that
have this ability will describe this in firmware.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benson Leung <bleung@chromium.org>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Gwendal Grignou <gwendal@chromium.org>
Cc: <devicetree@vger.kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210211024601.1963379-3-swboyd@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Stephen Boyd [Thu, 11 Feb 2021 02:45:59 +0000 (18:45 -0800)]
platform/chrome: cros_ec: Add SW_FRONT_PROXIMITY MKBP define
Some cros ECs support a front proximity MKBP event via
'EC_MKBP_FRONT_PROXIMITY'. Add this define so it can be used in a
future patch.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benson Leung <bleung@chromium.org>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Gwendal Grignou <gwendal@chromium.org>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210211024601.1963379-2-swboyd@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Gwendal Grignou [Tue, 9 Mar 2021 23:43:14 +0000 (15:43 -0800)]
iio: Remove kernel-doc keyword in file header comment
Remove kernel-doc keyword from function header comment.
It fixes issues spotted by scripts/kernel-doc like:
drivers/iio/<driver>.c:3: info: Scanning doc for function <component name>
drivers/iio/<driver>.c:X: warning: expecting prototype for <component name>.
Prototype was for <function>() instead
To reproduce the errors:
scripts/kernel-doc -v -none $(find drivers/iio/ -name \*.c \
-exec head -2 {} \+ | grep -B2 -e '\*\*' | grep '==' | cut -d ' ' -f 2)
After, confirm these errors are gone with:
scripts/kernel-doc -v -none $(git show --name-only | grep -e "^driver")
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20210309234314.2208256-1-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Sat, 6 Mar 2021 16:28:34 +0000 (18:28 +0200)]
iio: kfifo: mask flags without zero-check in devm_iio_kfifo_buffer_setup()
As pointed by Lars, this doesn't require a zero-check. Also, while looking
at this a little closer at it (again), the masking can be done later, as
there is a zero-check for 'mode_flags' anyway, which returns -EINVAL. And
we only need the 'mode_flags' later in the logic.
This change is more of a tweak.
Fixes:
e36db6a06937 ("iio: kfifo: add devm_iio_kfifo_buffer_setup() helper")
Cc: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210306162834.7339-1-ardeleanalex@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Gwendal Grignou [Fri, 26 Feb 2021 01:47:33 +0000 (17:47 -0800)]
iio: hrtimer: Allow sub Hz granularity
Allow setting frequency below 1Hz or sub 1Hz precision.
Useful for slow sensors like ALS.
Test frequency is set properly:
modprobe iio-trig-hrtimer && \
mkdir /sys/kernel/config/iio/triggers/hrtimer/t1 && \
cd /sys/bus/iio/devices/triggerX ;
for i in 1 .1 .01 .001 ; do
echo $i > sampling_frequency
cat sampling_frequency
done
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210226014733.2108544-1-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Baruch Siach [Tue, 23 Feb 2021 12:12:23 +0000 (14:12 +0200)]
staging: iio: remove mention of defunct list
The ADI device-drivers-devel list no longer exists.
Cc: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Link: https://lore.kernel.org/r/69b3e45e7666a1dd74a83df0b84ef8a63bf090ea.1614082343.git.baruch@tkos.co.il
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sean Nyekjaer [Mon, 1 Mar 2021 08:00:28 +0000 (09:00 +0100)]
iio: accel: mma8452: fix indentation
Improve readability by fixing indentation.
Signed-off-by: Sean Nyekjaer <sean@geanix.com>
Link: https://lore.kernel.org/r/20210301080029.1974797-1-sean@geanix.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ivan Mikhaylov [Thu, 25 Feb 2021 20:14:44 +0000 (23:14 +0300)]
iio: proximity: vcnl3020: add proximity rate
Add the proximity rate optional option and handling of it for
vishay vcnl3020.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
Link: https://lore.kernel.org/r/20210225201444.12983-2-i.mikhaylov@yadro.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sergiu Cuciurean [Mon, 28 Sep 2020 13:13:31 +0000 (16:13 +0300)]
iio: adc: npcm_adc: Replace indio_dev->mlock with own device lock
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
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: Mircea Caprioru <mircea.caprioru@analog.com>
Link: https://lore.kernel.org/r/20200928131333.36646-3-mircea.caprioru@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sergiu Cuciurean [Mon, 28 Sep 2020 13:13:30 +0000 (16:13 +0300)]
iio: adc: palmas_gpadc: Replace indio_dev->mlock with own device lock
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
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: Mircea Caprioru <mircea.caprioru@analog.com>
Link: https://lore.kernel.org/r/20200928131333.36646-2-mircea.caprioru@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sergiu Cuciurean [Mon, 28 Sep 2020 13:13:29 +0000 (16:13 +0300)]
iio: adc: spear_adc: Replace indio_dev->mlock with own device lock
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
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: Mircea Caprioru <mircea.caprioru@analog.com>
Link: https://lore.kernel.org/r/20200928131333.36646-1-mircea.caprioru@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Cameron [Sun, 17 Jan 2021 15:38:15 +0000 (15:38 +0000)]
iio:ABI docs: Combine the two instances of docs for sensor_sensitivity
This control on the gain of a measurement used for time of flight sensing
is standard but the expected values for different enviroments may not be.
As we cannot have the same ABI element documented in two files, add a
generic version to sysfs-bus-iio-proximity and a note on the expected
value vs measuring environment for the as3935.
Fixes
$ scripts/get_abi.pl validate
Warning: /sys/bus/iio/devices/iio:deviceX/sensor_sensitivity is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-distance-srf08:0 ./Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935:8
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20210117153816.696693-7-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Cameron [Sun, 17 Jan 2021 15:38:14 +0000 (15:38 +0000)]
iio:ABI docs: Combine sysfs-bus-iio-humidity-hdc2010/hdc100x into one file
These contain only one entry for out_current_heater_raw (_available).
Document this in a new sysfs-bus-iio-humidity file, and make it a little
more generic by allowing for non 0/1 values.
Fixes
$ scripts/get_abi.pl validate
Warning: /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc2010:0 ./Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x:0
Warning: /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw_available is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc2010:1 ./Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x:1
Cc: Eugene Zaikonnikov <ez@norphonic.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20210117153816.696693-6-jic23@kernel.org
Linus Walleij [Mon, 15 Feb 2021 15:34:47 +0000 (16:34 +0100)]
iio: adc: mt6360: Include right header
To get access to the big endian byte order parsing helpers
drivers need to include <asm/unaligned.h> and nothing else.
Cc: Gene Chen <gene_chen@richtek.com>
Suggested-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210215153447.48457-1-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Nuno Sa [Thu, 18 Feb 2021 11:40:39 +0000 (12:40 +0100)]
iio: adis: add helpers for locking
Add some helpers to lock and unlock the device. As this is such a simple
change, we update all the users that were using the lock already in this
patch.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210218114039.216091-5-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Nuno Sá [Thu, 18 Feb 2021 11:40:38 +0000 (12:40 +0100)]
dt-bindings: adis16475: remove property
`adi,scaled-output-hz` is no longer used by the driver.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210218114039.216091-4-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Nuno Sa [Thu, 18 Feb 2021 11:40:37 +0000 (12:40 +0100)]
iio: adis16475: improve sync scale mode handling
With this patch, we don't force users to define the IMU scaled internal
sampling rate once in the devicetree. Now it's dynamically calculated
at runtime depending on the desired output rate given by users.
Calculating the sync_scale dynamically gives us better chances of
achieving a perfect/integer value for DEC_RATE (thus giving more
flexibility). The math is:
1. lcm of the input clock and the desired output rate.
2. get the highest multiple of the previous result lower than the adis
max rate.
3. The last result becomes the IMU sample rate. Use that to calculate
SYNC_SCALE and DEC_RATE (to get the user output rate).
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210218114039.216091-3-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Nuno Sa [Thu, 18 Feb 2021 11:40:36 +0000 (12:40 +0100)]
iio: adis16480: fix pps mode sampling frequency math
When using PPS mode, the input clock needs to be scaled so that we have
an IMU sample rate between (optimally) 4000 and 4250. After this, we can
use the decimation filter to lower the sampling rate in order to get what
the user wants. Optimally, the user sample rate is a multiple of both the
IMU sample rate and the input clock. Hence, calculating the sync_scale
dynamically gives us better chances of achieving a perfect/integer value
for DEC_RATE. The math here is:
1. lcm of the input clock and the desired output rate.
2. get the highest multiple of the previous result lower than the adis
max rate.
3. The last result becomes the IMU sample rate. Use that to calculate
SYNC_SCALE and DEC_RATE (to get the user output rate).
Fixes:
326e2357553d3 ("iio: imu: adis16480: Add support for external clock")
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210218114039.216091-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Fri, 19 Feb 2021 09:01:34 +0000 (11:01 +0200)]
iio: adc: adi-axi-adc: fix typo in doc-string
The channels are of type iio_chan_spec, not axi_adc_chan_spec. They were in
some earlier version, but forgot to rename in the doc-string.
Fixes:
ef04070692a21 ("iio: adc: adi-axi-adc: add support for AXI ADC IP core")
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210219090134.48057-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Wed, 17 Feb 2021 08:34:34 +0000 (10:34 +0200)]
iio: Documentation: update definitions for bufferY and scan_elements
Since the new change to the IIO buffer infrastructure, the buffer/ and
scan_elements/ directories have been merged into bufferY/ to have some
attributes available per-buffer.
This change updates the ABI docs to reflect this change.
The hwfifo attributes are not updated, as for now these should be used
via the legacy buffer/ directory until they are moved into core.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210217083438.37865-2-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Mircea Caprioru [Wed, 17 Feb 2021 07:41:02 +0000 (09:41 +0200)]
iio: dac: ad5686: Add support for AD5673R/AD5677R
The AD5673R/AD5677R are low power, 16-channel, 12-/16-bit buffered voltage
output digital-to-analog converters (DACs). They include a 2.5 V internal
reference (enabled by default).
These devices are very similar to AD5674R/AD5679R, except that they
have an i2c interface.
Signed-off-by: Mircea Caprioru <mircea.caprioru@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210217074102.23148-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Hans de Goede [Mon, 15 Feb 2021 19:10:03 +0000 (20:10 +0100)]
iio: documentation: Document accelerometer label use
Some 2-in-1 laptops / convertibles with 360° (yoga-style) hinges,
have 2 accelerometers, 1 in their base and 1 in their display.
In many cases the kernel can detect the location of each accelerometer
based on e.g. information from the ACPI tables.
It is important for userspace to know the location of the 2 accelerometers.
Rather then adding a new sysfs-attribute for this we can relay this
information to userspace by using standardized label strings for this.
This mirrors how this is done for proximity sensors.
This commit documents 2 new standardized label strings for this purpose:
"accel-base"
"accel-display"
Note the "base" and "display" suffixes were chosen to match the values
used for the systemd/udev hwdb.d/60-sensor.hwdb file's ACCEL_LOCATION
property.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Mark Pearson <mpearson@lenovo.com>
Cc: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210215191003.698888-2-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Hans de Goede [Mon, 15 Feb 2021 19:10:02 +0000 (20:10 +0100)]
iio: documentation: Document proximity sensor label use
Add an entry to Documentation/ABI/testing/sysfs-bus-iio for
the new device label sysfs-attribute support.
And document the standardized labels which may be used with proximity
sensors to hint userspace about the intended use of the sensor.
Using labels to differentiate between the multiple proximity sensors
which a modern laptop/tablet may have was discussed in this thread:
https://lore.kernel.org/linux-iio/
9f9b0ff6-3bf1-63c4-eb36-
901cecd7c4d9@redhat.com/
As mentioned there the "proximity-wifi*" labels are already being used
in this manner on some chromebooks, see e.g.:
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
arch/arm64/boot/dts/qcom/sc7180-trogdor-lte-sku.dtsi
And the "proximity-palmrest" and "proximity-lap" labels are intended
to be used with the lap and palmrest sensors found in recent Lenovo
ThinkPad models.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Mark Pearson <mpearson@lenovo.com>
Cc: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210215191003.698888-1-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ye Xiang [Sun, 7 Feb 2021 07:00:48 +0000 (15:00 +0800)]
iio: Add relative hysteresis in ABI documentation
Add relative hysteresis in ABI documentation for als sensor.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
Link: https://lore.kernel.org/r/20210207070048.23935-4-xiang.ye@intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ye Xiang [Sun, 7 Feb 2021 07:00:47 +0000 (15:00 +0800)]
iio: hid-sensor-als: Add relative hysteresis support
Hid sensor als use relative hysteresis, this patch adds the support.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
Link: https://lore.kernel.org/r/20210207070048.23935-3-xiang.ye@intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ye Xiang [Sun, 7 Feb 2021 07:00:46 +0000 (15:00 +0800)]
iio: Add relative sensitivity support
Some hid sensors may use relative sensitivity such as als sensor.
This patch adds relative sensitivity checking for all hid sensors.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Link: https://lore.kernel.org/r/20210207070048.23935-2-xiang.ye@intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ye Xiang [Mon, 1 Feb 2021 05:49:21 +0000 (13:49 +0800)]
hid-sensors: Add more data fields for sensitivity checking
Before, when reading/writing the hysteresis of als, incli-3d, press, and
rotation sensor, we will get invalid argument error.
This patch add more sensitivity data fields for these sensors, so that
these sensors can get sensitivity index and return correct hysteresis
value.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
Link: https://lore.kernel.org/r/20210201054921.18214-3-xiang.ye@intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ye Xiang [Mon, 1 Feb 2021 05:49:20 +0000 (13:49 +0800)]
iio: hid-sensors: Move get sensitivity attribute to hid-sensor-common
No functional change has been made with this patch. The main intent here
is to reduce code repetition of getting sensitivity attribute.
In the current implementation, sensor_hub_input_get_attribute_info() is
called from multiple drivers to get attribute info for sensitivity
field. Moving this to common place will avoid code repetition.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210201054921.18214-2-xiang.ye@intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Luca Ceresoli [Mon, 15 Feb 2021 14:35:11 +0000 (15:35 +0100)]
docs: iio: mark "repeat" sysfs attribute as optional
Show that this field is optional, just like the shift value.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Link: https://lore.kernel.org/r/20210215143511.25471-6-luca@lucaceresoli.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Luca Ceresoli [Mon, 15 Feb 2021 14:35:10 +0000 (15:35 +0100)]
docs: iio: fix bullet list formatting
This 2nd-level bullet list is not properly ReST-formatted and thus it gets
rendered as a unique paragraph quite unreadable. Fix by adding spaces as
needed.
While there also swap "shift" and "repeat" so they are in the correct
order.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Link: https://lore.kernel.org/r/20210215143511.25471-5-luca@lucaceresoli.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Luca Ceresoli [Mon, 15 Feb 2021 14:35:09 +0000 (15:35 +0100)]
docs: iio: document the 'index' attribute too
Two out of three attributes are documented, document the third one too.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Link: https://lore.kernel.org/r/20210215143511.25471-4-luca@lucaceresoli.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Luca Ceresoli [Mon, 15 Feb 2021 14:35:08 +0000 (15:35 +0100)]
docs: iio: fix directory naming
This directory is a, well, directory, not a file.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Link: https://lore.kernel.org/r/20210215143511.25471-3-luca@lucaceresoli.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Luca Ceresoli [Mon, 15 Feb 2021 14:35:07 +0000 (15:35 +0100)]
docs: iio: fix example formatting
This line is part of the code snippet, so it has to be nested in order
to be rendered correctly.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Link: https://lore.kernel.org/r/20210215143511.25471-2-luca@lucaceresoli.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Julia Lawall [Tue, 9 Feb 2021 21:13:15 +0000 (22:13 +0100)]
iio: use getter/setter functions
Use getter and setter functions, for a variety of data types.
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Link: https://lore.kernel.org/r/20210209211315.1261791-1-Julia.Lawall@inria.fr
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:43 +0000 (12:40 +0200)]
tools: iio: convert iio_generic_buffer to use new IIO buffer API
This change makes use of the new IIO buffer API to read data from an IIO
buffer.
It doesn't read the /sys/bus/iio/devices/iio:deviceX/scan_elements dir
anymore, it reads /sys/bus/iio/devices/iio:deviceX/bufferY, where all the
scan_elements have been merged together with the old/classical buffer
attributes.
And it makes use of the new IIO_BUFFER_GET_FD_IOCTL ioctl to get an FD for
the IIO buffer for which to read data from.
It also does a quick sanity check to see that -EBUSY is returned if reading
the chardev after the ioctl() has succeeded.
This was tested with the following cases:
1. Tested buffer0 works with ioctl()
2. Tested that buffer0 can't be opened via /dev/iio:deviceX after ioctl()
This check should be omitted under normal operation; it's being done
here to check that the driver change is sane
3. Moved valid buffer0 to be buffer1, and tested that data comes from it
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-25-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:42 +0000 (12:40 +0200)]
tools: iio: privatize globals and functions in iio_generic_buffer.c file
Mostly a tidy-up.
But also helps to understand the limits of scope of these functions and
globals.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-24-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:41 +0000 (12:40 +0200)]
tools: iio: make iioutils_get_type() private in iio_utils
This is a bit of a tidy-up, but also helps with extending the
iioutils_get_type() function a bit, as we don't need to use it outside of
the iio_utils.c file. So, we'll need to update it only in one place.
With this change, the 'unsigned' types are updated to 'unsigned int' in the
iioutils_get_type() function definition.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-23-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:40 +0000 (12:40 +0200)]
iio: core: rename 'dev' -> 'indio_dev' in iio_device_alloc()
The 'dev' variable name usually refers to 'struct device' types. However in
iio_device_alloc() this was used for the 'struct iio_dev' type, which was
sometimes causing minor confusions.
This change renames the variable to 'indio_dev', which is the usual name
used around IIO for 'struct iio_dev' type objects.
It makes grepping a bit easier as well.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-22-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:39 +0000 (12:40 +0200)]
iio: buffer: add ioctl() to support opening extra buffers for IIO device
With this change, an ioctl() call is added to open a character device for a
buffer. The ioctl() number is 'i' 0x91, which follows the
IIO_GET_EVENT_FD_IOCTL ioctl.
The ioctl() will return an FD for the requested buffer index. The indexes
are the same from the /sys/iio/devices/iio:deviceX/bufferY (i.e. the Y
variable).
Since there doesn't seem to be a sane way to return the FD for buffer0 to
be the same FD for the /dev/iio:deviceX, this ioctl() will return another
FD for buffer0 (or the first buffer). This duplicate FD will be able to
access the same buffer object (for buffer0) as accessing directly the
/dev/iio:deviceX chardev.
Also, there is no IIO_BUFFER_GET_BUFFER_COUNT ioctl() implemented, as the
index for each buffer (and the count) can be deduced from the
'/sys/bus/iio/devices/iio:deviceX/bufferY' folders (i.e the number of
bufferY folders).
Used following C code to test this:
-------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <fcntl.h"
#include <errno.h>
#define IIO_BUFFER_GET_FD_IOCTL _IOWR('i', 0x91, int)
int main(int argc, char *argv[])
{
int fd;
int fd1;
int ret;
if ((fd = open("/dev/iio:device0", O_RDWR))<0) {
fprintf(stderr, "Error open() %d errno %d\n",fd, errno);
return -1;
}
fprintf(stderr, "Using FD %d\n", fd);
fd1 = atoi(argv[1]);
ret = ioctl(fd, IIO_BUFFER_GET_FD_IOCTL, &fd1);
if (ret < 0) {
fprintf(stderr, "Error for buffer %d ioctl() %d errno %d\n", fd1, ret, errno);
close(fd);
return -1;
}
fprintf(stderr, "Got FD %d\n", fd1);
close(fd1);
close(fd);
return 0;
}
-------------------------------------------------------------------
Results are:
-------------------------------------------------------------------
# ./test 0
Using FD 3
Got FD 4
# ./test 1
Using FD 3
Got FD 4
# ./test 2
Using FD 3
Got FD 4
# ./test 3
Using FD 3
Got FD 4
# ls /sys/bus/iio/devices/iio\:device0
buffer buffer0 buffer1 buffer2 buffer3 dev
in_voltage_sampling_frequency in_voltage_scale
in_voltage_scale_available
name of_node power scan_elements subsystem uevent
-------------------------------------------------------------------
iio:device0 has some fake kfifo buffers attached to an IIO device.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-21-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:38 +0000 (12:40 +0200)]
iio: buffer: introduce support for attaching more IIO buffers
With this change, calling iio_device_attach_buffer() will actually attach
more buffers.
Right now this doesn't do any validation of whether a buffer is attached
twice; maybe that can be added later (if needed). Attaching a buffer more
than once should yield noticeably bad results.
The first buffer is the legacy buffer, so a reference is kept to it.
At this point, accessing the data for the extra buffers (that are added
after the first one) isn't possible yet.
The iio_device_attach_buffer() is also changed to return an error code,
which for now is -ENOMEM if the array could not be realloc-ed for more
buffers.
To adapt to this new change iio_device_attach_buffer() is called last in
all place where it's called. The realloc failure is a bit difficult to
handle during un-managed calls when unwinding, so it's better to have this
as the last error in the setup_buffer calls.
At this point, no driver should call iio_device_attach_buffer() directly,
it should call one of the {devm_}iio_triggered_buffer_setup() or
devm_iio_kfifo_buffer_setup() or devm_iio_dmaengine_buffer_setup()
functions. This makes iio_device_attach_buffer() a bit easier to handle.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-20-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:37 +0000 (12:40 +0200)]
iio: dummy: iio_simple_dummy_buffer: use triggered buffer core calls
The iio_simple_dummy_configure_buffer() function is essentially a
re-implementation of the iio_triggered_buffer_setup() function.
This change makes use of the iio_triggered_buffer_setup() function. The
reason is so that we don't have to modify the iio_device_attach_buffer()
function in this driver as well.
One minor drawback is that the pollfunc name may not be 100% identical
with the one in the original code, but since it's an example, it should be
a big problem.
This change does a minor re-arranging of the included iio headers, as a
minor tidy-up.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-19-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:36 +0000 (12:40 +0200)]
iio: buffer: move __iio_buffer_free_sysfs_and_mask() before alloc
The __iio_buffer_free_sysfs_and_mask() function will be used in
iio_buffer_alloc_sysfs_and_mask() when multiple buffers will be attached to
the IIO device.
This will need to be used to cleanup resources on each buffer, when the
buffers cleanup unwind will occur on the error path.
The move is done in this patch to make the patch that adds multiple buffers
per IIO device a bit cleaner.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-18-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:35 +0000 (12:40 +0200)]
iio: core: wrap iio device & buffer into struct for character devices
In order to keep backwards compatibility with the current chardev
mechanism, and in order to add support for multiple buffers per IIO device,
we need to pass both the IIO device & IIO buffer to the chardev.
This is particularly needed for the iio_buffer_read_outer() function, where
we need to pass another buffer object than 'indio_dev->buffer'.
Since we'll also open some chardevs via anon inodes, we can pass extra
buffers in that function by assigning another object to the
iio_dev_buffer_pair object.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-17-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:34 +0000 (12:40 +0200)]
iio: buffer: dmaengine: obtain buffer object from attribute
The reference to the IIO buffer object is stored on the attribute object.
So we need to unwind it to obtain it.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-16-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:33 +0000 (12:40 +0200)]
iio: buffer: wrap all buffer attributes into iio_dev_attr
This change wraps all buffer attributes into iio_dev_attr objects, and
assigns a reference to the IIO buffer they belong to.
With the addition of multiple IIO buffers per one IIO device, we need a way
to know which IIO buffer is being enabled/disabled/controlled.
We know that all buffer attributes are device_attributes. So we can wrap
them with a iio_dev_attr types. In the iio_dev_attr type, we can also hold
a reference to an IIO buffer.
So, we end up being able to allocate wrapped attributes for all buffer
attributes (even the one from other drivers).
The neat part with this mechanism, is that we don't need to add any extra
cleanup, because these attributes are being added to a dynamic list that
will get cleaned up via iio_free_chan_devattr_list().
With this change, the 'buffer->scan_el_dev_attr_list' list is being renamed
to 'buffer->buffer_attr_list', effectively merging (or finalizing the
merge) of the buffer/ & scan_elements/ attributes internally.
Accessing these new buffer attributes can now be done via
'to_iio_dev_attr(attr)->buffer' inside the show/store handlers.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-15-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:32 +0000 (12:40 +0200)]
iio: add reference to iio buffer on iio_dev_attr
This change adds a reference to a 'struct iio_buffer' object on the
iio_dev_attr object. This way, we can use the created iio_dev_attr objects
on per-buffer basis (since they're allocated anyway).
A minor downside of this change is that the number of parameters on
__iio_add_chan_devattr() grows by 1. This looks like it could do with a bit
of a re-think.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-14-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:31 +0000 (12:40 +0200)]
iio: core: merge buffer/ & scan_elements/ attributes
With this change, we create a new directory for the IIO device called
buffer0, under which both the old buffer/ and scan_elements/ are stored.
This is done to simplify the addition of multiple IIO buffers per IIO
device. Otherwise we would need to add a bufferX/ and scan_elementsX/
directory for each IIO buffer.
With the current way of storing attribute groups, we can't have directories
stored under each other (i.e. scan_elements/ under buffer/), so the best
approach moving forward is to merge their attributes.
The old/legacy buffer/ & scan_elements/ groups are not stored on the opaque
IIO device object. This way the IIO buffer can have just a single
attribute_group object, saving a bit of memory when adding multiple IIO
buffers.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-13-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:30 +0000 (12:40 +0200)]
iio: buffer: group attr count and attr alloc
If we want to merge the attributes of the buffer/ and scan_elements/
directories, we'll need to count all attributes first, then (depending on
the attribute group) either allocate 2 attribute groups, or a single one.
Historically an IIO buffer was described by 2 subdirectories under
/sys/bus/iio/iio:devicesX (i.e. buffer/ and scan_elements/); these subdirs
were actually 2 separate attribute groups on the iio_buffer object.
Moving forward, if we want to allow more than one buffer per IIO device,
keeping 2 subdirectories for each IIO buffer is a bit cumbersome
(especially for userpace ABI). So, we will merge the attributes of these 2
subdirs under a /sys/bus/iio/iio:devicesX/bufferY subdirectory. To do this,
we need to count all attributes first, and then distribute them based on
which buffer this is. For the first buffer, we'll need to also allocate the
legacy 2 attribute groups (for buffer/ and scan_elements/), and also a
/sys/bus/iio/iio:devicesX/buffer0 attribute group.
For buffer1 and above, just a single attribute group will be allocated (the
merged one).
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-12-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:29 +0000 (12:40 +0200)]
iio: core: rework iio device group creation
Up until now, the device groups that an IIO device had were limited to 6.
Two of these groups would account for buffer attributes (the buffer/ and
scan_elements/ directories).
Since we want to add multiple buffers per IIO device, this number may not
be enough, when adding a second buffer. So, this change reallocates the
groups array whenever an IIO device group is added, via a
iio_device_register_sysfs_group() helper.
This also means that the groups array should be assigned to
'indio_dev.dev.groups' really late, right before {cdev_}device_add() is
called to do the entire setup.
And we also must take care to free this array when the sysfs resources are
being cleaned up.
With this change we can also move the 'groups' & 'groupcounter' fields to
the iio_dev_opaque object. Up until now, this didn't make a whole lot of
sense (especially since we weren't sure how multibuffer support would look
like in the end).
But doing it now kills one birds with one stone.
An alternative, would be to add a configurable Kconfig symbol
CONFIG_IIO_MAX_BUFFERS_PER_DEVICE (or something like that) and compute a
static maximum of the groups we can support per IIO device. But that would
probably annoy a few people since that would make the system less
configurable.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-11-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:28 +0000 (12:40 +0200)]
iio: core-trigger: make iio_device_register_trigger_consumer() an int return
Oddly enough the noop function is an int-return. This one seems to be void.
This change converts it to int, because we want to change how groups are
registered. With that change this function could error out with -ENOMEM.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-10-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:27 +0000 (12:40 +0200)]
iio: core: register chardev only if needed
We only need a chardev if we need to support buffers and/or events.
With this change, a chardev will be created only if an IIO buffer is
attached OR an event_interface is configured.
Otherwise, no chardev will be created, and the IIO device will get
registered with the 'device_add()' call.
Quite a lot of IIO devices don't really need a chardev, so this is a minor
improvement to the IIO core, as the IIO device will take up (slightly)
fewer resources.
In order to not create a chardev, we mostly just need to not initialize the
indio_dev->dev.devt field. If that is un-initialized, cdev_device_add()
behaves like device_add().
This change has a small chance of breaking some userspace ABI, because it
removes un-needed chardevs. While these chardevs (that are being removed)
have always been unusable, it is likely that some scripts may check their
existence (for whatever logic).
And we also hope that before opening these chardevs, userspace would have
already checked for some pre-conditions to make sure that opening these
chardevs makes sense.
For the most part, there is also the hope that it would be easier to change
userspace code than revert this. But in the case that reverting this is
required, it should be easy enough to do it.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-9-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:26 +0000 (12:40 +0200)]
docs: ioctl-number.rst: reserve IIO subsystem ioctl() space
Currently, only the 'i' 0x90 ioctl() actually exists and is defined in
'include/uapi/linux/iio/events.h'.
It's the IIO_GET_EVENT_FD_IOCTL, which is used to retrieve and FD for
reading events from an IIO device.
We will want to add more ioct() numbers, so with this change the 'i'
0x90-0x9F space is reserved for IIO ioctl() calls.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-8-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:25 +0000 (12:40 +0200)]
iio: buffer-dma,adi-axi-adc: introduce devm_iio_dmaengine_buffer_setup()
This change does a conversion of the devm_iio_dmaengine_buffer_alloc() to
devm_iio_dmaengine_buffer_setup(). This will allocate an IIO DMA buffer and
attach it to the IIO device, similar to devm_iio_triggered_buffer_setup()
(though the underlying code is different, the final logic is the same).
Since the only user of the devm_iio_dmaengine_buffer_alloc() was the
adi-axi-adc driver, this change does the replacement in a single go in the
driver.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-7-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:24 +0000 (12:40 +0200)]
iio: kfifo: un-export devm_iio_kfifo_allocate() function
At this point all drivers should use devm_iio_kfifo_buffer_setup() instead
of manually allocating via devm_iio_kfifo_allocate() and assigning ops and
modes.
With this change, the devm_iio_kfifo_allocate() will be made private to the
IIO core, since all drivers should call either
devm_iio_kfifo_buffer_setup() or devm_iio_triggered_buffer_setup() to
create a kfifo buffer.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-6-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:23 +0000 (12:40 +0200)]
iio: accel: sca3000: use devm_iio_kfifo_buffer_setup() helper
This change makes use of the devm_iio_kfifo_buffer_setup() helper, however
the unwind order is changed.
The life-time of the kfifo object is attached to the parent device object.
This is to make the driver a bit more consistent with the other IIO
drivers, even though (as it is now before this change) it shouldn't be a
problem.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-5-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:22 +0000 (12:40 +0200)]
iio: make use of devm_iio_kfifo_buffer_setup() helper
All drivers that already call devm_iio_kfifo_allocate() &
iio_device_attach_buffer() are simple to convert to
iio_device_attach_kfifo_buffer() in a single go.
This change does that; the unwind order is preserved.
What is important, is that the devm_iio_kfifo_buffer_setup() be called
after the indio_dev->modes is assigned, to make sure that
INDIO_BUFFER_SOFTWARE flag is set and not overridden by the assignment to
indio_dev->modes.
Also, the INDIO_BUFFER_SOFTWARE has been removed from the assignments of
'indio_dev->modes' because it is set by devm_iio_kfifo_buffer_setup().
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>x
Link: https://lore.kernel.org/r/20210215104043.91251-4-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 15 Feb 2021 10:40:21 +0000 (12:40 +0200)]
iio: kfifo: add devm_iio_kfifo_buffer_setup() helper
This change adds the devm_iio_kfifo_buffer_setup() helper/short-hand,
which groups the simple routine of allocating a kfifo buffers via
devm_iio_kfifo_allocate() and calling iio_device_attach_buffer().
The mode_flags parameter is required, as the IIO kfifo supports 2 modes:
INDIO_BUFFER_SOFTWARE & INDIO_BUFFER_TRIGGERED.
The setup_ops parameter is optional.
This function will be a bit more useful when needing to define multiple
buffers per IIO device.
The naming for this function has been inspired from
iio_triggered_buffer_setup() since that one does a kfifo alloc + a pollfunc
alloc. So, this should have a more familiar ring to what it is.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-3-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Lars-Peter Clausen [Tue, 15 Dec 2020 19:17:43 +0000 (20:17 +0100)]
iio: Add basic unit test for iio_format_value()
The IIO core provides a function to do formatting of fixedpoint numbers.
In the past there have been some issues with the implementation of the
function where for example negative numbers were not handled correctly.
Introduce a basic unit test based on kunit that tests the function and
ensures that the generated output matches the expected output.
This gives us some confidence that future modifications to the function
implementation will not break ABI compatibility.
To run the unit tests follow the kunit documentation and add
CONFIG_IIO=y
CONFIG_IIO_TEST_FORMAT=y
to the .kunitconfig and run
> ./tools/testing/kunit/kunit.py run
Configuring KUnit Kernel ...
Building KUnit Kernel ...
Starting KUnit Kernel ...
============================================================
======== [PASSED] iio-format ========
[PASSED] iio_test_iio_format_value_integer
[PASSED] iio_test_iio_format_value_fixedpoint
[PASSED] iio_test_iio_format_value_fractional
[PASSED] iio_test_iio_format_value_fractional_log2
[PASSED] iio_test_iio_format_value_multiple
============================================================
Testing complete. 21 tests run. 0 failed. 0 crashed.
Elapsed time: 8.242s total, 0.001s configuring, 3.865s building, 0.000s running
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20201215191743.2725-3-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Lars-Peter Clausen [Tue, 15 Dec 2020 19:17:42 +0000 (20:17 +0100)]
iio: iio_format_value(): Fix IIO_VAL_FRACTIONAL_LOG2 values between -1.0 and 0.0
When formatting a value using IIO_VAL_FRACTIONAL_LOG2 and the values is
between -1 and 0 the sign is omitted.
We need the same trick as for IIO_VAL_FRACTIONAL to make sure this gets
formatted correctly.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20201215191743.2725-2-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Lars-Peter Clausen [Tue, 15 Dec 2020 19:17:41 +0000 (20:17 +0100)]
iio: iio_format_value(): Use signed temporary for IIO_VAL_FRACTIONAL_LOG2
IIO_VAL_FRACTIONAL_LOG2 works with signed values, yet the temporary we use
is unsigned. This works at the moment because the variable is implicitly
cast to signed everywhere where it is used.
But it will certainly be cleaner to use a signed variable in the first
place.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20201215191743.2725-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Bhaskar Chowdhury [Wed, 10 Feb 2021 08:57:04 +0000 (14:27 +0530)]
iio: proximity: sx9500: Fix a spelling postive to positive
s/postive/positive/
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20210210085704.1228068-1-unixbhaskar@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Hans de Goede [Sun, 7 Feb 2021 16:09:01 +0000 (17:09 +0100)]
iio: accel: kxcjk-1013: Set label based on accel-location on 2-accel yoga-style 2-in-1s
Some 2-in-1 laptops / convertibles with 360° (yoga-style) hinges,
use 2 KXCJ91008 accelerometers:
1 in their display using an ACPI HID of "KIOX010A"; and
1 in their base using an ACPI HID of "KIOX020A"
Since in this case we know the location of each accelerometer,
set the label for the accelerometers to the standardized
"accel-display" resp. "accel-base" labels. This way userspace
can use the labels to get the location.
This was tested on a Medion Akoya E2228T MD60250.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210207160901.110643-4-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Hans de Goede [Sun, 7 Feb 2021 16:09:00 +0000 (17:09 +0100)]
iio: accel: bmc150: Set label based on accel-location on 2-accel yoga-style 2-in-1s
Some 2-in-1 laptops / convertibles with 360° (yoga-style) hinges,
use 2 bmc150 accelerometers, defined by a single BOSC0200 ACPI
device node (1 in their base and 1 in their display).
Since in this case we know the location of each accelerometer,
set the label for the accelerometers to the standardized
"accel-display" resp. "accel-base" labels. This way userspace
can use the labels to get the location.
This was tested on a Lenovo ThinkPad Yoga 11e 4th gen (N3450 CPU).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210207160901.110643-3-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Hans de Goede [Sun, 7 Feb 2021 16:08:59 +0000 (17:08 +0100)]
iio: core: Allow drivers to specify a label without it coming from of
Only set indio_dev->label from of/dt if there actually is a label
specified in of.
This allows drivers to set a label without this being overwritten with
NULL when there is no label specified in of. This is esp. useful on
devices where of is not used at all, such as your typical x86/ACPI device.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210207160901.110643-2-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tomislav Denis [Tue, 2 Feb 2021 08:41:07 +0000 (09:41 +0100)]
bindings: iio: adc: Add documentation for ADS131E0x ADC driver
Add a device tree binding documentation for Texas Instruments
ADS131E0x ADC family driver.
Signed-off-by: Tomislav Denis <tomislav.denis@avl.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210202084107.3260-3-tomislav.denis@avl.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tomislav Denis [Tue, 2 Feb 2021 08:41:06 +0000 (09:41 +0100)]
iio: adc: Add driver for Texas Instruments ADS131E0x ADC family
The ADS131E0x are a family of multichannel, simultaneous sampling,
24-bit, delta-sigma, analog-to-digital converters (ADCs) with a
built-in programmable gain amplifier (PGA), internal reference
and an onboard oscillator.
Datasheet: https://www.ti.com/lit/ds/symlink/ads131e08.pdf
Signed-off-by: Tomislav Denis <tomislav.denis@avl.com>
Link: https://lore.kernel.org/r/20210202084107.3260-2-tomislav.denis@avl.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Mike Looijmans [Mon, 25 Jan 2021 15:07:32 +0000 (16:07 +0100)]
iio: accel: Add support for the Bosch-Sensortec BMI088
The BMI088 is a combined module with both accelerometer and gyroscope.
This adds the accelerometer driver support for the SPI interface.
The gyroscope part is already supported by the BMG160 driver.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210125150732.23873-2-mike.looijmans@topic.nl
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Mike Looijmans [Mon, 25 Jan 2021 15:07:31 +0000 (16:07 +0100)]
dt-bindings: iio: accel: Add bmi088 accelerometer bindings
This adds the device-tree bindings for the Bosch Sensortec BMI088 IMU,
the accelerometer part.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210125150732.23873-1-mike.looijmans@topic.nl
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
zuoqilin [Thu, 28 Jan 2021 02:19:05 +0000 (10:19 +0800)]
iio:adc:dac:ad5791 typo fix of regster
change 'regster' to 'register'
Signed-off-by: zuoqilin <zuoqilin@yulong.com>
Link: https://lore.kernel.org/r/20210128021905.963-1-zuoqilin1@163.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Peter Meerwald-Stadler [Mon, 25 Jan 2021 19:56:54 +0000 (20:56 +0100)]
MAINTAINERS: iio: move Peter Meerwald-Stadler to CREDITS
Haven't had much time lately and moved on to different things.
Thanks Jonathan for the gentle introduction to Linux land.
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20210125195654.580465-1-pmeerw@pmeerw.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ahmad Fatoum [Mon, 25 Jan 2021 19:48:23 +0000 (20:48 +0100)]
iio: adc: stm32-adc: enable timestamping for non-DMA usage
For non-DMA usage, we have an easy way to associate a timestamp with a
sample: iio_pollfunc_store_time stores a timestamp in the primary
trigger IRQ handler and stm32_adc_trigger_handler runs in the IRQ thread
to push out the buffer along with the timestamp.
For this to work, the driver needs to register an IIO_TIMESTAMP channel.
Do this.
For DMA, it's not as easy, because we don't push the buffers out of
stm32_adc_trigger, but out of stm32_adc_dma_buffer_done, which runs in
a tasklet scheduled after a DMA completion.
Preferably, the DMA controller would copy us the timestamp into that buffer
as well. Until this is implemented, restrict timestamping support to
only PIO. For low-frequency sampling, PIO is probably good enough.
Cc: Holger Assmann <has@pengutronix.de>
Acked-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.kernel.org/r/20210125194824.30549-1-a.fatoum@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ye Xiang [Sat, 30 Jan 2021 10:25:46 +0000 (18:25 +0800)]
iio: hid-sensor-rotation: Fix quaternion data not correct
Because the data of HID_USAGE_SENSOR_ORIENT_QUATERNION defined by ISH FW
is s16, but quaternion data type is in_rot_quaternion_type(le:s16/32X4>>0),
need to transform data type from s16 to s32
May require manual backporting.
Fixes:
fc18dddc0625 ("iio: hid-sensors: Added device rotation support")
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
Link: https://lore.kernel.org/r/20210130102546.31397-1-xiang.ye@intel.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
William Breathitt Gray [Sat, 30 Jan 2021 02:37:03 +0000 (11:37 +0900)]
counter: 104-quad-8: Remove IIO counter ABI
The IIO counter driver has been superseded by the Counter subsystem as
discussed in [1]. This patch removes the IIO counter ABI from the
104-QUAD-8 driver.
[1] https://lore.kernel.org/lkml/
20210119104105.
000010df@Huawei.com/
Cc: Syed Nayyar Waris <syednwaris@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Link: https://lore.kernel.org/r/98a39983d5df761c058a469d1346fd8ffdef8516.1611973018.git.vilhelm.gray@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fabrice Gasnier [Fri, 29 Jan 2021 13:22:22 +0000 (14:22 +0100)]
counter: stm32-lptimer-cnt: remove iio counter abi
Currently, the STM32 LP Timer counter driver registers into both IIO and
counter subsystems, which is redundant.
Remove the IIO counter ABI and IIO registration from the STM32 LP Timer
counter driver since it's been superseded by the Counter subsystem
as discussed in [1].
Keep only the counter subsystem related part.
Move a part of the ABI documentation into a driver comment.
This also removes a duplicate ABI warning
$ scripts/get_abi.pl validate
...
/sys/bus/iio/devices/iio:deviceX/in_count0_preset is defined 2 times:
./Documentation/ABI/testing/sysfs-bus-iio-timer-stm32:100
./Documentation/ABI/testing/sysfs-bus-iio-lptimer-stm32:0
[1] https://lkml.org/lkml/2021/1/19/347
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Link: https://lore.kernel.org/r/1611926542-2490-1-git-send-email-fabrice.gasnier@foss.st.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Cameron [Sun, 24 Jan 2021 19:10:22 +0000 (19:10 +0000)]
iio:adc:stm32-adc: Add HAS_IOMEM dependency
Seems that there are config combinations in which this driver gets enabled
and hence selects the MFD, but with out HAS_IOMEM getting pulled in
via some other route. MFD is entirely contained in an
if HAS_IOMEM block, leading to the build issue in this bugzilla.
https://bugzilla.kernel.org/show_bug.cgi?id=209889
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ahmad Fatoum [Thu, 21 Jan 2021 15:39:44 +0000 (16:39 +0100)]
iio: st_sensors: fix typo in comment
s/timetamping/timestamping/
Cc: trivial@kernel.org
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.kernel.org/r/20210121153945.5499-1-a.fatoum@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Klemen Košir [Wed, 3 Mar 2021 09:01:34 +0000 (18:01 +0900)]
staging: unisys: visornic: Fix repeated words in comments
This patch removes some repeated words in code comments.
Signed-off-by: Klemen Košir <klemen.kosir@kream.io>
Link: https://lore.kernel.org/r/20210303090134.16007-1-klemen.kosir@kream.io
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Song Chen [Tue, 12 Jan 2021 08:25:40 +0000 (16:25 +0800)]
staging: unisys: visornic: enhance visornic to use channel_interrupt
visornic uses timer to check the response queue and drain
it if needed periodically. On the other hand, visorbus
provides periodic work to serve such request, therefore,
timer should be replaced by channel_interrupt.
Signed-off-by: Song Chen <chensong_2000@189.cn>
Link: https://lore.kernel.org/r/1610439940-5590-1-git-send-email-chensong_2000@189.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kumar Kartikeya Dwivedi [Sun, 21 Feb 2021 15:42:59 +0000 (21:12 +0530)]
staging/greybus: eliminate use of NAME_SIZE for strings
Instead, depend on the size of the destination buffer for easier
refactoring.
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20210221154258.119503-1-memxor@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gustavo A. R. Silva [Thu, 4 Mar 2021 02:02:28 +0000 (20:02 -0600)]
staging: rtl8188eu: Replace one-element array with flexible-array in struct ndis_802_11_var_ie
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Use flexible-array member in struct ndis_802_11_var_ie, instead of
one-element array.
Also, this helps with the ongoing efforts to enable -Warray-bounds by
fixing the following warning:
drivers/staging/rtl8188eu/core/rtw_wlan_util.c: In function ‘HT_caps_handler’:
drivers/staging/rtl8188eu/core/rtw_wlan_util.c:665:65: warning: array subscript 2 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds]
665 | if ((pmlmeinfo->HT_caps.ampdu_params_info & 0x3) > (pIE->data[i] & 0x3))
| ~~~~~~~~~^~~
[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/109
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20210304020228.GA45139@embeddedor
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marco Cesati [Fri, 5 Mar 2021 10:01:46 +0000 (11:01 +0100)]
staging: HalBtc8723b1Ant: remove useless typedef's
This commit fixes the following checkpatch.pl warnings:
WARNING: do not add new typedefs
#24: FILE: hal/HalBtc8723b1Ant.h:24:
+typedef enum _BT_INFO_SRC_8723B_1ANT {
WARNING: do not add new typedefs
#31: FILE: hal/HalBtc8723b1Ant.h:31:
+typedef enum _BT_8723B_1ANT_BT_STATUS {
WARNING: do not add new typedefs
#41: FILE: hal/HalBtc8723b1Ant.h:41:
+typedef enum _BT_8723B_1ANT_WIFI_STATUS {
WARNING: do not add new typedefs
#51: FILE: hal/HalBtc8723b1Ant.h:51:
+typedef enum _BT_8723B_1ANT_COEX_ALGO {
WARNING: do not add new typedefs
#66: FILE: hal/HalBtc8723b1Ant.h:66:
+typedef struct _COEX_DM_8723B_1ANT {
WARNING: do not add new typedefs
#121: FILE: hal/HalBtc8723b1Ant.h:121:
+typedef struct _COEX_STA_8723B_1ANT {
Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
Link: https://lore.kernel.org/r/20210305100146.30687-1-marco.cesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marco Cesati [Fri, 5 Mar 2021 10:11:51 +0000 (11:11 +0100)]
staging: HalBtc8723b2Ant: remove useless typedef's
This commit fixes the following checkpatch.pl warnings:
WARNING: do not add new typedefs
#19: FILE: hal/HalBtc8723b2Ant.h:19:
+typedef enum _BT_INFO_SRC_8723B_2ANT {
WARNING: do not add new typedefs
#26: FILE: hal/HalBtc8723b2Ant.h:26:
+typedef enum _BT_8723B_2ANT_BT_STATUS {
WARNING: do not add new typedefs
#36: FILE: hal/HalBtc8723b2Ant.h:36:
+typedef enum _BT_8723B_2ANT_COEX_ALGO {
WARNING: do not add new typedefs
#51: FILE: hal/HalBtc8723b2Ant.h:51:
+typedef struct _COEX_DM_8723B_2ANT {
WARNING: do not add new typedefs
#104: FILE: hal/HalBtc8723b2Ant.h:104:
+typedef struct _COEX_STA_8723B_2ANT {
Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
Link: https://lore.kernel.org/r/20210305101151.13137-1-marco.cesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Denis Efremov [Fri, 5 Mar 2021 15:50:01 +0000 (18:50 +0300)]
staging: rtl8723bs: remove duplicate pstat->hwaddr check
IS_MCAST(pstat->hwaddr) checked twice in a row in
odm_RefreshRateAdaptiveMaskCE(). Remove the second check.
Signed-off-by: Denis Efremov <efremov@linux.com>
Link: https://lore.kernel.org/r/20210305155001.61951-1-efremov@linux.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marco Cesati [Fri, 5 Mar 2021 14:49:06 +0000 (15:49 +0100)]
staging: rtl8723bs: remove useless typedef's in HalPhyRf.h
This commit fixes the following checkpatch.pl warnings:
WARNING: do not add new typedefs
#11: FILE: hal/HalPhyRf.h:11:
+typedef enum _SPUR_CAL_METHOD {
WARNING: do not add new typedefs
#16: FILE: hal/HalPhyRf.h:16:
+typedef enum _PWRTRACK_CONTROL_METHOD {
WARNING: do not add new typedefs
#27: FILE: hal/HalPhyRf.h:27:
+typedef struct _TXPWRTRACK_CFG {
Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
Link: https://lore.kernel.org/r/20210305144906.18850-1-marco.cesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fabio Aiuto [Fri, 5 Mar 2021 19:17:16 +0000 (20:17 +0100)]
staging: rtl8723bs: removed unused code block
Removed conditional code block checked by unused CONFIG_TX_BCAST2UNI
This patch does the cleaning required in TODO file:
find and remove code blocks guarded by never set CONFIG_FOO defines
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/20210305191713.GA2466@agape.jhs
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Straube [Sat, 6 Mar 2021 08:11:33 +0000 (09:11 +0100)]
staging: rtl8188eu: rename parameters of odm_phy_status_query()
Rename parameters of odm_phy_status_query() to avoid camel case.
pDM_Odm -> dm_odm
pPhyInfo -> phy_info
pPhyStatus -> phy_status
pPktinfo -> pkt_info
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20210306081133.1272-2-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Straube [Sat, 6 Mar 2021 08:11:32 +0000 (09:11 +0100)]
staging: rtl8188eu: rename ODM_PhyStatusQuery()
Rename ODM_PhyStatusQuery() to odm_phy_status_query() to avoid camel
case.
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20210306081133.1272-1-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jia-Ju Bai [Sat, 6 Mar 2021 13:22:45 +0000 (05:22 -0800)]
staging: vc04_services: vchiq_arm: fix error return code of vchiq_release_internal() and vchiq_use_internal()
When arm_state is NULL, no error return code of vchiq_release_internal()
and vchiq_use_internal() is assigned.
To fix this bug, ret is assigned with VCHIQ_ERROR.
Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Link: https://lore.kernel.org/r/20210306132245.16811-1-baijiaju1990@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Giovanni Gherdovich [Sat, 6 Mar 2021 14:13:22 +0000 (15:13 +0100)]
staging: ralink-gdma: Check return code of device_reset
The device_reset() function is marked as "__must_check", thus the static
analysis tool "sparse" complains that in ralink-gdma its return value is
ignored. Log a warning in case it returns an error.
Signed-off-by: Giovanni Gherdovich <bobdc9664@seznam.cz>
Link: https://lore.kernel.org/r/20210306141322.7516-1-bobdc9664@seznam.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>