Age | Commit message (Collapse) | Author |
|
The inv_mpu6050 driver manually assigns the indio_dev->modes property. But
this is not necessary since it will be setup in iio_trigger_buffer_setup().
Remove the manual assignment.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Link: https://lore.kernel.org/r/20210325131046.13383-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
As Lars pointed out, we could either return the FD vs memcpy-ing it to the
userspace data object.
However, this comment exposed a bug. We should return 0 or negative from
these ioctl() handlers. Because an ioctl() handler can also return
IIO_IOCTL_UNHANDLED (which is positive 1), which means that the ioctl()
handler doesn't support this ioctl number. Positive 1 could also be a valid
FD number in some corner cases.
The reason we did this is to be able to differentiate between an error
code and an unsupported ioctl number; for unsupported ioctl numbers, the
main loop should keep going.
Maybe we should change this to a higher negative number, to avoid such
cases when/if we add more ioctl() handlers.
Cc: Lars-Peter Clausen <lars@metafoo.de>
Fixes: f73f7f4da5818 ("iio: buffer: add ioctl() to support opening extra buffers for IIO device")
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210322084135.17536-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The code was checking if (ret) from the processed
channel readout, not smart, we need to check if (ret < 0)
as this will likely be something like IIO_VAL_INT.
Fixes: 635ef601b238 ("iio: Provide iio_read_channel_processed_scale() API")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210323122705.1326362-1-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Registers the device using the devm variant.
This is the final step of converting the ad7923 to only use devm routines,
meaning that the ad7923_remove() function is no longer needed to release
resources on device detach.
Signed-off-by: Lucas Stankus <lucas.p.stankus@gmail.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/b0146465d52f4e259f5f95c83c71e72f065093da.1616966903.git.lucas.p.stankus@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Converts the iio_triggered_buffer_setup() call to its device-managed
counterpart.
With this, the error handling routine in the ad7923_probe() function
becomes unnecessary as well as the iio_triggered_buffer_cleanup() call.
Signed-off-by: Lucas Stankus <lucas.p.stankus@gmail.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/fe46a45caaa788f333d78367968272de728f4a6e.1616966903.git.lucas.p.stankus@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Adds a device-managed action to handle disabling the driver's regulator on
device detach.
This slightly simplifies deinitialization and enables further conversion of
the driver to device-managed routines without breaking the init order.
Signed-off-by: Lucas Stankus <lucas.p.stankus@gmail.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/49a7c0436ca1186313dbccf3d810d0cf38cb5b37.1616966903.git.lucas.p.stankus@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
s/concurent/concurrent/
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20210323012215.451075-1-unixbhaskar@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
It may happen that the MPU6050 is the only hardware
trigger available on your system such as this:
> lsiio
Device 003: hscdtd008a
Device 001: mpu6050
Device 002: gp2ap002
Device 000: ab8500-gpadc
Trigger 000: mpu6050-dev1
And when you want to use it to read periodically from
your magnetometer like this:
> iio_generic_buffer -a -c 100 -n hscdtd008a -t mpu6050-dev1
Then the following happens:
[ 209.951334] Internal error: Oops: 5 [#1] SMP ARM
(...)
[ 209.981969] Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)
[ 209.988925] PC is at inv_scan_query_mpu6050+0x8/0xb8
[ 209.993914] LR is at inv_mpu6050_set_enable+0x40/0x194
This is because since we are not using any channels from the
same device, the indio_dev->active_scan_mask is NULL.
Just checking for that and bailing out is however not enough:
we have to enable some kind of FIFO for the readout to work.
So enable the temperature as a dummy FIFO and all works
fine.
Not suitable for backporting to stable. It is an odd corner case
and does not represent a regression.
Fixes: 09a642b78523 ("Invensense MPU6050 Device Driver.")
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Link: https://lore.kernel.org/r/20210322132408.1003443-1-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Whilst running some basic tests as part of writing up the dt-bindings for
this driver (to follow), it became clear it doesn't actually load
currently.
iio iio:device1: tried to double register : in_incli_x_index
adis16201 spi0.0: Failed to create buffer sysfs interfaces
adis16201: probe of spi0.0 failed with error -16
Looks like a cut and paste / update bug. Fixes tag obviously not accurate
but we don't want to bother carry thing back to before the driver moved
out of staging.
Fixes: 591298e54cea ("Staging: iio: accel: adis16201: Move adis16201 driver out of staging")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: <Stable@vger.kernel.org>
Cc: Himanshu Jha <himanshujha199640@gmail.com>
Cc: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210321182956.844652-1-jic23@kernel.org
|
|
Update DAC drivers powerdown attribute show callback to use the new
sysfs_emit() function.
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it
knows about the sysfs buffer specifics and has some built-in sanity checks.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210320071405.9347-5-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it
knows about the sysfs buffer specifics and has some built-in sanity checks.
Convert __iio_format_value() and related functions to use this new
interface.
This conversion involves changing the signature of __iio_format_value() so
that it similar to sysfs_emit_at() and takes the buffers start address and
an offset where to write within the buffer.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210320071405.9347-4-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it
knows about the sysfs buffer specifics and has some built-in sanity checks.
Convert the iio_enum_available_read() function to use sysfs_emit_at()
instead of scnprintf().
The conversion is straight forward, the only difference is that
sysfs_emit_at() takes the buffers start address and an offset as parameters
and already knows about the buffer's size limit.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210320071405.9347-3-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it
knows about the sysfs buffer specifics and has some built-in sanity checks.
This patch converts the places in the iio core that follow the pattern of
return s*printf(...)
to
return sysfs_emit(...)
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210320071405.9347-2-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The plural of "matrix" is "matrices".
Signed-off-by: Guoqing Chi <chiguoqing@yulong.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Link: https://lore.kernel.org/r/20210322013024.1849-1-chi962464zy@163.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
1st set of IIO/counter device support, features and cleanup in the 5.13 cycle
Big set in here from Alexandru Ardelean enabling multiple buffer support.
This includes providing a new directory per buffer that combines
what was previously in buffer/ and scan_elements/. Old interfaces still
in place for compatiblity.
Note immuatable branch for scmi patches to allow for some significant
rework going on in that subsystem. Merge required updating to reflect
some changes in IIO.
Late rebase to fix some wrong fixes tags due to some earlier rebases
made necessary by messing up the immutable branch.
IIO New Device Support
* adi,ad5686
- Add info to support AD5673R and AD5677R
* bosch,bmi088
- New driver supporting this accelerometer + gyroscope
* cros_ec_mkbp
- New driver for this proximity sensor that exposes a 'front'
sensor. Very simple switch like device, but driver allows it
to share interface with more sophisticated proximity sensors.
* iio_scmi
- New driver to support ARM SCMI protocol to expose underlying
accelerometers and gyroscopes via this firmware interface.
* st,st_magn
- Add ID for IISMDC magnetometer.
* ti,ads131e0
- New driver supporting ads131e04, ads131e06 and ads131e08 24 bit ADCs
Counter New Device Support
* IRQ or GPIO based counter
- New driver for a conceptually simple counter that uses interrupts
to perform the count.
Features
* core
- Dual buffer supprt including:
Various helpers to centralize handling of bufferer related elements.
Document existing and new IOCTLs
Register the IIO chrdev only if it can actually be used for anything.
Rework attribute group creation in the core (lots of patches)
Merge buffer/ and scan_elements/ entries into one list + maintain
backwards compatible set.
Introduce the internal logic and IOCTL to allow multiple buffers
+ access to an anon FD per buffer to actually read from it.
Tidy up tools/iio/iio_generic_buffer and switch to new interfaces.
Update ABI docs.
A few follow up fixes, unsuprising as this was a huge bit of rework.
- Move common case setting of trig->parent to the core.
- Provide an iio_read_channel_processed_scale() to avoid loss of
precision from iio_read_channel_processed() then applying integer
scale. Use it in ntc_thermistor driver in hwmon.
- Allow drivers to specify labels from elsewhere than DT. Use it for
bmc150 and kxcjk-1013 labels related to position on 2 in one tablets.
- Document label usage for proximity and accelerometer sensors.
- Some local variable renames for consistency
tools
- Add -a parameter to iio_event_monitor to allow autoenabling of events.
* acpi_als
- Add trigger support for devices that don't support notification method.
* adi,ad7124
- Allow more than 8 channels. This is a complex little device, but is
capable of supporting up to 16 channels if the share certain
configuration settings.
* hrtimer-trigger
- Support sampling frequency below 1Hz.
* mediatek,mt8195-auxadc
- Add compatible to binding docs (always also includes mt8173)
* st,stm32-adc
- Enable timetamps when not using DMA.
* vishay,vcnl3020
- Sampling frequency control.
Cleanup and minor fixes:
* treewide
- Use some getter and setter functions instead of opencoding.
- Set of fixes for pointless casts in various drivers.
- Avoid wrong kernel-doc marking on comment blocks.
- Fix various other minor kernel-doc issues shown by W=1
* core
- Use a signed temporary for IIO_VAL_FRACTIONAL_LOG2 to avoid odd casts.
- Fix IIO_VAL_FRACTIONAL_LOG2 for values between -1.0 and 0.0
- Add unit tests for iio_format_value()
* docs
- Fix formatting/typos in iio_configfs.rst and buffers.rst
- Add documentation of index in buffers.rst
- Fix scan element description
- Avoid some issues with HTML generation from ABI docs by moving
duplicated defintions to more generic files.
- Drop reference to long dead mailing list.
* 104-quad
- Remove left over deprecated IIO counter ABI.
* adi,adi-axi-adc
- Fix wrong bit of docs.
* adi,ad5791
- Typos
* adi,ad9834
- Switch to device managed functions in probe.
* adi,adis*
- Add and use helpers for locking to reduced duplication.
* adi,adis16480
- Fix calculation of sampling frequency when using pulse per second input.
* adi,adis16475
- Calculate the IMU scaled internal sampling rate and runtime depending
on sysfs based configuration rather than getting from DT. Drop now
unnecessary property from DT bindings doc.
* cros_ec
- Fix result of a series of recent changes that means extended buffer
attributes turn up in the wrong place. Too complex to revert the
various patches unfortunately so this is a bit messy.
* fsl,mma3452
- Indentation cleanup.
* hid-sensors
- Size of storage needs to increase for some parts when using quaternions.
- Move the get sensistivity attribute to hid-sensors-common to reduce
duplication. Enable it for more device types.
- Correctly handle relative sensitivity if reported that way including
documenting the new ABI.
* maxim,max517
- Use device managed functions in probe.
* mediatek,mt6360-adc
- Use asm/unaligned.h instead of directly including
unaligned/be_byteshift.h
* novuton,npcm-adc
- Local lock instead of missusing mlock.
* semtech,sx9500
- Typos
* st,sensor
- typo fix
* st,spear-adc
- Local lock instead of missusing mlock.
* st,stm32-adc
- Long standing HAS_IOMEM dependency fix.
* st,stm32-counter
- Remove left over deprecated IIO counter ABI.
* ti,palmas-adc
- Local lock instead of missusing mlock.
* ti,tmp007
- Switch to device managed functions in probe.
Other
* MAINTAINERS
- Move Peter Meerwald-Stadler to Credits at his request
* tag 'iio-for-5.13a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (119 commits)
iio: acpi_als: Add trigger support
iio: acpi_als: Add local variable dev in probe
iio: acpi_als: Add timestamp channel
iio: adc: ad7292: Modify the bool initialization assignment
iio: cros: unify hw fifo attributes without API changes
iio: kfifo: add devm_iio_triggered_buffer_setup_ext variant
iio: event_monitor: Enable events before monitoring
dt-bindings: iio: adc: Add compatible for Mediatek MT8195
iio:magnetometer: Add Support for ST IIS2MDC
dt-bindings: iio: st,st-sensors add IIS2MDC.
staging: iio: ad9832: kernel-doc fixes
iio:dac:max517.c: Use devm_iio_device_register()
iio:cros_ec_sensors: Fix a wrong function name in kernel doc.
iio: buffer: kfifo_buf: kernel-doc, typo in function name.
iio: accel: sca3000: kernel-doc fixes. Missing - and wrong function names.
iio: adc: adi-axi-adc: Drop false marking for kernel-doc
iio: adc: cpcap-adc: kernel-doc fix - that should be _ in structure name
iio: dac: ad5504: fix wrong part number in kernel-doc structure name.
iio: dac: ad5770r: kernel-doc fix case of letter R wrong in structure name
iio: adc: ti-adc084s021: kernel-doc fixes, missing function names
...
|
|
Updated to use devm_iio_kfifo_buffer_setup() in place of now
removed devm_iio_kfifo_allocate()
Take3 branch because first 2 versions including wrong version of
patch.
|
|
As some firmware does not notify on illuminance changes, add a
trigger to be able to query light via software (sysfs-trigger or
hrtrigger).
Add a hardware trigger set as the default trigger to maintain backward
compatibility.
Check iio_info reports the sensor as buffer capable:
iio:device0: acpi-als (buffer capable)
To test, check we can get data on demand on an Intel based chromebook:
IIO_DEV="iio:device0"
echo 1 > iio_sysfs_trigger/add_trigger
cat trigger2/name > ${IIO_DEV}/trigger/current_trigger
for i in ${IIO_DEV}/scan_elements/*_en ${IIO_DEV}/buffer/enable ; do
echo 1 > $i
done
od -x /dev/${IIO_DEV} &
echo 1 > trigger2/trigger_now
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210317074012.2336454-4-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Use dev = &device->dev in probe routine for clarity.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210317074012.2336454-3-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add timestamp channel in list of channel, to allow retrieving timestamps
when events are produced.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210317074012.2336454-2-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
A bool initializer is best assigned to false rather than 0.
Signed-off-by: Guoqing Chi <chiguoqing@yulong.com>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Link: https://lore.kernel.org/r/20210319062706.5135-1-chi962464zy@163.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Commit 2e2366c2d141 ("iio: cros_ec: unify hw fifo attributes into the core file")
should be reverted as it set buffer extended attributes at
the wrong place. However, to revert it will requires to revert more
commits:
commit 165aea80e2e2 ("iio: cros_ec: use devm_iio_triggered_buffer_setup_ext()")
commit 21232b4456ba ("iio: buffer: remove iio_buffer_set_attrs() helper")).
and we would still have conflict with more recent development.
commit ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers")
Instead, this commit reverts the first 2 commits without re-adding
iio_buffer_set_attrs() and set the buffer extended attributes at the
right place:
1. Instead of adding has_fw_fifo, deduct it from the configuration:
- EC must support FIFO (EC_FEATURE_MOTION_SENSE_FIFO) set.
- sensors send data a regular interval (accelerometer, gyro,
magnetomer, barometer, light sensor).
- "Legacy accelerometer" is only present on EC without FIFO, so we don't
need to set buffer attributes.
2. devm_iio_triggered_buffer_setup_ext() does not need to be called when
EC does not support FIFO, as there is no FIFO to manage.
3. Use devm_iio_triggered_buffer_setup_ext() when EC has a FIFO to
specify the buffer extended attributes.
Fixes: 2e2366c2d141 ("iio: cros_ec: unify hw fifo attributes into the core file")
Fixes: 165aea80e2e2 ("iio: cros_ec: use devm_iio_triggered_buffer_setup_ext()")
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210318184857.2679181-1-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This is similar to the {devm_}iio_triggered_buffer_setup_ext variants added
via commit 5164c7889857 ("iio: triggered-buffer: add
{devm_}iio_triggered_buffer_setup_ext variants").
These can be used to pass extra buffer attributes to the buffer object.
This is a bit of temporary mechanism (hopefully) so that drivers that want
to allocate a kfifo buffer with extra buffer attributes, don't need to
include 'buffer_impl.h' directly. This can also become an API function (in
it's own right, unfortunately), but it may be a little less bad vs drivers
having to include 'buffer_impl.h'.
So, far the drivers that want to pass buffer attributes, all have to do
with some HW FIFO attributes, so there may be a chance of unifying them
into IIO core somehow (as some standard API). But, until that happens, we
just need to let them register their HW FIFO attributes directly (without
having to let them include 'buffer_impl.h' directly).
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210311091042.22417-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
After some painful sessions with a driver that register an
enable/disable sysfs knob (gp2ap002) and manually going
in and enabling the event before monitoring it:
cd /sys/bus/iio/devices/iio\:device2/events
# ls
in_proximity_thresh_either_en
# echo 1 > in_proximity_thresh_either_en
I realized that it's better if the iio_event_monitor is
smart enough to enable all events by itself and disable them
after use, if passed the -a flag familiar from the
iio_generic_buffer tool.
Auto-enabling events depend on the hardware being able
to handle all events at the same time which isn't
necessarily the case, so a command line option is required
for this.
Cc: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210319135301.542911-1-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This commit adds dt-binding documentation of auxadc for Mediatek MT8195 SoC
Platform.
Signed-off-by: Seiya Wang <seiya.wang@mediatek.com>
Link: https://lore.kernel.org/r/20210319023427.16711-7-seiya.wang@mediatek.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add support for ST magnetometer IIS2MDC,
an I2C/SPI interface 3-axis magnetometer.
The patch was tested on the instrument with IIS2MDC via I2C interface.
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
Link: https://lore.kernel.org/r/20210317063902.19300-3-Qing-wu.Li@leica-geosystems.com.cn
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add support for ST magnetometer IIS2MDC,
an I2C/SPI interface 3-axis magnetometer sensor.
The patch was tested on the instrument with IIS2MDC via I2C interface.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
Link: https://lore.kernel.org/r/20210317063902.19300-2-Qing-wu.Li@leica-geosystems.com.cn
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Fixes a W=1 warning.
-Added ``:`` to lock parameter in 'ad9832_state' description.
-It's a reference comment so removed /**
Signed-off-by: Mugilraj Dhavachelvan <dmugil2000@gmail.com>
Link: https://lore.kernel.org/r/20210315133711.26860-1-dmugil2000@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Use devm_iio_device_register() to avoid remove function and
drop explicit call to iio_device_unregister().
Signed-off-by: Mugilraj Dhavachelvan <dmugil2000@gmail.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210314175709.34301-1-dmugil2000@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
cros_ec_sensors_read_data_unsafe() had wrong function name in kernel-doc
This shows up with W=1 builds.
No fixes tag because I don't want to waste time on this being
backported.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Gwendal Grignou <gwendal@chromium.org>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20210313145341.116088-1-jic23@kernel.org
|
|
Should have been _kfifo_ and was _fifo_
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210314164655.408461-9-jic23@kernel.org
|
|
All extremely obvious so nothing to add to patch title.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210314164655.408461-8-jic23@kernel.org
|
|
This comment block isn't in kernel-doc format so drop the /** marking.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210314164655.408461-7-jic23@kernel.org
|
|
Fixes a W=1 warning.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210314164655.408461-6-jic23@kernel.org
|
|
Probably a bit of cut and paste where someone forgot to change the
part number.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210314164655.408461-5-jic23@kernel.org
|
|
Nothing useful to add beyond this causing a warning with W=1
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210314164655.408461-4-jic23@kernel.org
|
|
The documentation in this driver was nearly kernel-doc and was marked
as such. Unfortunately the format was wrong and function names were
missing. This patch puts them in with minor edits to keep the resulting
line short.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Gwendal Grignou <gwendal@chromium.org>
Cc: Mårten Lindahl <martenli@axis.com>
Link: https://lore.kernel.org/r/20210314164655.408461-3-jic23@kernel.org
|
|
Two comment blocks had wrong naming for function/structures that they
referred to. Results in warnings when doing a W=1 build.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210314164655.408461-2-jic23@kernel.org
|
|
Add simple IRQ or GPIO base counter. This device is used to measure
rotation speed of some agricultural devices, so no high frequency on the
counter pin is expected.
The maximal measurement frequency depends on the CPU and system load. On
the idle iMX6S I was able to measure up to 20kHz without count drops.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Reviewed-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Link: https://lore.kernel.org/r/20210301080401.22190-3-o.rempel@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add binding for the interrupt counter node
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210301080401.22190-2-o.rempel@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This change converts the driver to use device-managed functions in the
probe function. For the clock and regulator disable, some
devm_add_action_or_reset() calls are required, and then
devm_iio_device_register() function can be used register the IIO device.
The final aim here would be for IIO to export only the device-managed
functions of it's API. That's a long way to go and this a small step in
that direction.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210310095131.47476-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This change converts the driver to use device-managed functions in the
probe function. The power-down call is handled now via a
devm_add_action_or_reset() hook, and then devm_iio_device_register() can be
used to register the IIO device.
The final aim here would be for IIO to export only the device-managed
functions of it's API. That's a long way to go and this a small step in
that direction.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210310093800.45822-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Thanks to Lars for finding this.
The free of the 'attached_buffers' array should be done as late as
possible. This change moves it to iio_buffers_put(), which looks like
the best place for it, since it takes place right before the IIO device
data is free'd.
The free of this array will be handled by calling iio_device_free().
The iio_buffers_put() function is renamed to iio_device_detach_buffers()
since the role of this function changes a bit.
It looks like this issue was ocurring on the error path of
iio_buffers_alloc_sysfs_and_mask() and in
iio_buffers_free_sysfs_and_mask()
Added a comment in the doc-header of iio_device_attach_buffer() to
mention how this will be free'd in case anyone is reading the code
and becoming confused about it.
Fixes: ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210307185444.32924-1-ardeleanalex@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Before trying the custom method of reading the sensor
as raw and then converting, we want to use
iio_read_channel_processed_scale() which first tries to
see if the ADC can provide a processed value directly,
else reads raw and applies scaling inside of IIO
using the scale attributes of the ADC. We need to
multiply the scaled value with 1000 to get to
microvolts from millivolts which is what processed
IIO channels returns.
Keep the code that assumes 12bit ADC around as a
fallback.
This gives correct readings on the AB8500 thermistor
inputs used in the Ux500 HREFP520 platform for reading
battery and board temperature.
Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org
Link: https://lore.kernel.org/linux-iio/20201224011607.1059534-1-linus.walleij@linaro.org/
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Chris Lesiak <chris.lesiak@licor.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20210308100219.2732156-2-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Since the old iio_read_channel_processed() would
lose precision if we fall back to reading raw and
scaling, we introduce a new API that will pass in
a scale factor when reading a processed channel:
iio_read_channel_processed_scale().
Refactor iio_read_channel_processed() as a special
case with scale factor 1.
Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org
Link: https://lore.kernel.org/linux-iio/20201224011607.1059534-1-linus.walleij@linaro.org/
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210308100219.2732156-1-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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.
In xadc_alloc_trigger, given dev is indio_dev->dev.parent, and we call
devm_iio_trigger_alloc wit dev as argument, we do not have to set
data->trig->dev.parent to indio_dev->dev.parent 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-9-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 we call devm_iio_trigger_alloc() and devm_iio_device_alloc() with
dev as parent, we do not have to set data->trig->dev.parent to
indio_dev->dev.parent 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-8-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 we call devm_iio_trigger_alloc() and devm_iio_device_alloc() with
&client->dev as parent, we do not have to set data->trig->dev.parent to
indio_dev->dev.parent 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-7-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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>
|
|
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>
|
|
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>
|