Age | Commit message (Collapse) | Author |
|
Using these newer macros allows the compiler to remove the unused
structure and functions when !CONFIG_PM_SLEEP + removes the need to
mark pm functions __maybe_unused.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Christian Eggers <ceggers@arri.de>
Reviewed-by: Christian Eggers <ceggers@arri.de>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220621202719.13644-22-jic23@kernel.org
|
|
Using these newer macros allows the compiler to remove the unused
structure and functions when !CONFIG_PM_SLEEP + removes the need to
mark pm functions __maybe_unused.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: David Heidelberg <david@ixit.cz>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220621202719.13644-21-jic23@kernel.org
|
|
Using these newer macros allows the compiler to remove the unused
structure and functions when !CONFIG_PM_SLEEP + removes the need to
mark pm functions __maybe_unused.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: David Heidelberg <david@ixit.cz>
Reviewed-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220621202719.13644-20-jic23@kernel.org
|
|
Instead of registering callback to process sensor events right at
initialization time, wait for the sensor to be register in the iio
subsystem.
Events can come at probe time (in case the kernel rebooted abruptly
without switching the sensor off for instance), and be sent to IIO core
before the sensor is fully registered.
Fixes: aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO")
Reported-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20220711144716.642617-1-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The read on in_illuminance_input keeps at 0 after system sleep.
So add proper suspend and resume callback to make the sensor keep
working after system sleep.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20220707000151.33381-1-kai.heng.feng@canonical.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
cancel_delayed_work_sync().
Since cancel_delayed_work(&chip->poweroff_work) does not guarantee that
tsl2563_poweroff_work() is not running, tsl2563_set_power(chip, 0) can be
called from tsl2563_poweroff_work() after tsl2563_get_power(chip) and
tsl2563_set_power(chip, 1) are called. Use _sync version in order to make
sure that tsl2563_poweroff_work() is no longer running.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Link: https://lore.kernel.org/r/041b6745-f784-ff3f-9836-3f4397d35d94@I-love.SAKURA.ne.jp
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
cancel_delayed_work_sync().
Commit 9e61d901155bcd4e ("iio: light: tsl2563: Remove
flush_scheduled_work") replaced cancel_delayed_work() +
flush_scheduled_work() with cancel_delayed_work_sync() for only
tsl2563_probe() side.
Do the same thing for tsl2563_remove() side, which was added by
commit 388be4883952872b ("staging:iio: tsl2563 abi fixes and interrupt
handling").
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Link: https://lore.kernel.org/r/3381176e-2f86-24ba-a8ba-c4ce8f416086@I-love.SAKURA.ne.jp
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Do not trust the fact that iio.h includes of.h which in turn includes
all the headers we are relying on.
The ultimate goal is to actually drop of.h from iio.h.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220610084545.547700-17-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220515155929.338656-9-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220515155929.338656-8-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220515155929.338656-7-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220515155929.338656-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
When sensor location is known, populate iio sysfs "label" attribute:
* "accel-base" : the sensor is in the base of the convertible (2-1)
device.
* "accel-display" : the sensor is in the lid/display plane of the
device.
* "accel-camera" : the sensor is in the swivel camera subassembly.
The non-standard |location| attribute is removed, the field |loc| in
cros_ec_sensors_core_state is removed.
It apply to standalone accelerometer as well as IMU (accelerometer +
gyroscope) and sensors where the location is known (light).
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20220427190804.961697-3-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Returning an error value in an i2c remove callback results in an error
message being emitted by the i2c core, but otherwise it doesn't make a
difference. The device goes away anyhow and the devm cleanups are
called.
As tsl2583_set_power_state() already emits an error message on failure
and the additional error message by the i2c core doesn't add any useful
information, change the return value to zero to suppress this message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220430081607.15078-10-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Returning an error value in an i2c remove callback results in an error
message being emitted by the i2c core, but otherwise it doesn't make a
difference. The device goes away anyhow and the devm cleanups are
called.
As stk3310_set_state() already emits an error message on failure and the
additional error message by the i2c core doesn't add any useful
information, change the return value to zero to suppress this message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220430081607.15078-9-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Returning an error value in an i2c remove callback results in an error
message being emitted by the i2c core, but otherwise it doesn't make a
difference. The device goes away anyhow and the devm cleanups are
called.
As opt3001_remove() already emits an error message on failure and the
additional error message by the i2c core doesn't add any useful
information, change the return value to zero to suppress this message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220430081607.15078-8-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Returning an error value in an i2c remove callback results in an error
message being emitted by the i2c core, but otherwise it doesn't make a
difference. The device goes away anyhow and the devm cleanups are
called.
As jsa1212_power_off() already emits an error message on failure and the
additional error message by the i2c core doesn't add any useful
information, change the return value to zero to suppress this message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220430081607.15078-7-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Returning an error value in an i2c remove callback results in an error
message being emitted by the i2c core, but otherwise it doesn't make a
difference. The device goes away anyhow and the devm cleanups are
called.
As isl29028_clear_configure_ret() already emits an error message on
failure and the additional error message by the i2c core doesn't add any
useful information, change the return value to zero to suppress this
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220430081607.15078-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Returning an error value in an i2c remove callback results in an error
message being emitted by the i2c core, but otherwise it doesn't make a
difference. The device goes away anyhow and the devm cleanups are
called.
As bh1780_remove() already emits an error message on failure and the
additional error message by the i2c core doesn't add any useful
information, change the return value to zero to suppress this message.
While at it, add the error code to the remaining error message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220430081607.15078-5-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This makes the value from which an object should be considered "near"
available to userspace. This hardware-dependent value should be set
in the device-tree.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
Link: https://lore.kernel.org/r/20220420112540.91907-3-arnaud.ferraris@collabora.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Convert the module to be property provider agnostic and allow
it to be used on non-OF platforms.
While at it, reuse temporary device pointer in the same function.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220413181402.19582-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Nothing in this driver depends on OF firmware so drop the dependency
to remove the false impression such a dependency exists.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220413184627.21125-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Among all the users of the kfifo buffers, no one uses the
INDIO_BUFFER_HARDWARE mode. So let's take this as a general rule and
simplify a little bit the internals - overall the documentation - by
eliminating unused specific cases. Use the INDIO_BUFFER_SOFTWARE mode by
default with kfifo buffers, which will basically mimic what all the "non
direct" modes do.
Cc: Benson Leung <bleung@chromium.org>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Jyoti Bhayana <jbhayana@google.com>
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20220207143840.707510-13-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Mikko Koivunen <mikko.koivunen@fi.rohmeurope.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-50-jic23@kernel.org
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Use the new DEFINE_RUNTIME_DEV_PM_OPS to reduce boilerplate.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-47-jic23@kernel.org
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-29-jic23@kernel.org
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Vaishnav M A <vaishnav@beagleboard.org>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-28-jic23@kernel.org
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-27-jic23@kernel.org
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-26-jic23@kernel.org
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Icenowy Zheng <icenowy@aosc.io>
Cc: Luca Weiss <luca@z3ntu.xyz>
Cc: Martijn Braam <martijn@brixit.nl>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-25-jic23@kernel.org
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Maslov Dmitry <maslovdmitry@seeed.cc>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-24-jic23@kernel.org
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-23-jic23@kernel.org
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-22-jic23@kernel.org
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Anson Huang <anson.huang@nxp.com>
Cc: Brian Masney <masneyb@onstation.org>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-21-jic23@kernel.org
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards. Also switch to SIMPLE_DEV_PM_OPS rather
than opencoding the same.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-20-jic23@kernel.org
|
|
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-19-jic23@kernel.org
|
|
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the bus specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-16-jic23@kernel.org
|
|
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it
knows about the sysfs buffer specifics and has some built-in checks for
size and alignment.
Use sysfs_emit() to format the custom device attributes of the lm3533
driver. Note this driver was using scnprintf correctly so this change
is about ensuring examples of code that might get cut and paste into new
drivers are using current best practice.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211216185217.1054495-8-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The final entry was missing a space. Tidy that up.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211230174911.78291-15-jic23@kernel.org
|
|
The spacing in this driver was inconsistent so make sure we have a space
after { and before } for the two id tables.
Part of aim is to avoid providing examples of this inconsistency that
get copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Nikita Travkin <nikita@trvn.ru>
Cc: Maslov Dmitry <maslovdmitry@seeed.cc>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211230174911.78291-6-jic23@kernel.org
|
|
The spacing in this driver was inconsistent so make sure we have a space
after { and before } for the two id tables.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211230174911.78291-5-jic23@kernel.org
|
|
Having a space after the { and not one before the } is inconsistent and
I'd rather not have examples of this that get copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Parthiban Nallathambi <pn@denx.de>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211230174911.78291-4-jic23@kernel.org
|
|
before }
One case in here was inconsistent and was main focus of this patch.
In that case there was a space after the { and none before the }.
The second case was then inconsistent in having now spaces.
Change makes sure there are spaces.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211230174911.78291-3-jic23@kernel.org
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next
Jonathan writes:
1st set of IIO new device support, features and cleanup for 5.17
Includes some fixes that were either late breaking, low priority or
complex enough to not be good to rush in late in the cycle.
Tree rebased today to fix up some trivial issues + pull in a fix that
was previously on the fixes-togreg branch. Vast majority have been
in linux-next for some time now.
New device support
* adi,ad7293
- New driver and bindings for this Power Amplifier drain current
controller. A complex device with various related monitoring functions.
* adi,ad75513R
- New driver and bindings for this combined ADC and DAC device.
- A few follow up fixes.
* adi,admv8818
- New driver (and type) for this 2-18GHz filter device. Includes
bindings and ABI documentation to allow clk_notifier based auto
adjustment of the filters in appropriate applications.
* liteon,ltr501
- Support for the ltr303. ID and chip specific info table.
* xilinx,ams
- New generic firmware function fwnode_iomap() as used in this driver.
- New driver and bindings for this ADC and on-chip sensors as found
in various Xilinx devices.
Core
* Introduced IIO_VAL_INT_64 which uses val and val2 in IIO callbacks to
form a 64 bit integer when higher precision needed.
* Allow IIO_ENUM_AVAILABLE to be used with different shared values.
* Fix a long term issue with scheduling whilst atomic when iio_trig_poll()
is called but no trigger consumers are actually enabled and hence the
trigger may be reenabled from the interrupt handler. Seen in the wild
on the tsc2046.
* Mark iio_device_type const.
* buffer: Use a separate index variable to simplify code.
* buffer-dma: Clear out unused struct iio_buffer_block
* buffer-dmaengine: Switch to cheaper round_down() as power of 2 values.
Tests/tools
* format_value
- Check against NULL returns from allocations in tests.
- Add IIO_VAL_INT_64 test case.
* event_monitor
- Flush the output after event to given more consistent latency
when tool output piped to other programs.
Driver Features
* axp20x
- Add support for NTC thermistor channel and document TS pin binding.
* arm,scmi
- Add reading of raw channel values (using IIO_VAL_INT_64)
* liteon,ltr501
- Add proximity-near-level support and dt-binding.
Tree wide cleanup
* Remove no-op trigger ops from multiple drivers.
* Stop using dev_get_drvdata() on the iio_dev->dev in various drivers
and then stop assigning it to allow this to be used for other purposes.
We can always get to the indio_dev using dev_to_iio_dev() which is
a container_of() based approach. Also cleanup up some related unnecessary
convoluted cases.
- atmel,at91-sam5d2
- nxp,imx7d
- meas,ms5611
- st,st_sensors
* Where available (or easy to introduce) use the scan_type.* values
in place of a second copy for read_raw and similar paths.
- adi,ad7266
- bosch,bma220
- fsl,mac3110
- fsl,mma7455
- fsl,mpl3115
- kionix,kcjk-1013
- sensortek,stk8ba50
- sensortek,stk8312
- ti,adc12138
- ti,ads1015
- vti,sca3000
- xilinx,xadc-core
* Switch drives over to generic firmware properties including appropriate
header changes to avoid including of.h
- Various DACs had false CONFIG_OF dependencies.
- dpot-dac
- envelope-detector
- adi,ad5755
- adi,ad5758
- capella,cm3605
- maxim,max9611
- microchip,mcp41010
- microchip,mcp3911
- ti,adc12138
* Trivial clang warning fixes for W=1 warnings.
Driver specific cleanup and minor fixes
* adi,ad7606
- Comment fixes.
* ams,ad3935
- Drop pointless cast to the same type.
* atmel,at91-sama5d2
- Fix wrong cast of iio_dev->dev to platform_device that happened to
be harmless.
* fsl,mma7660
- Stop i2c remove() function returning an error code. Part of a rework
to eventually stop returning anything from these.
* fsl,mma8452
- Use correct type for local irqreturn_t.
* nxp,imx8mq
- Maintainer email address update.
* nxp,lpc18xx_adc
- Ensure clk_prepare_enable() called before clk_get_rate().
- Switch of.h for mod_devicetable.h to reflect no of specific functions,
just the id table.
* renesas,rzg2l
- Drop a dev_err() that just duplicates error printed in platform_get_irq()
* sgx,vz89x
- Drop pointless cast.
* st,lsm6dsx
- Make it possible to disable the sensorhub from DT to avoid a corner
case where the address of a slave device many be accidentally modified.
* st,stm32-adc
- Stop leaking an of_node in an error path.
* st,stmp2
- Avoid wrong sized type for bit field which could result in
over-reading (harmless). Precursor to enabling -Warray-bounds.
* ti,adc081c
- Put back some ACPI support for non standards compliant ADC081C
ID because it is known to be in the wild on some Aaeon boards.
* ti,ads8688
- Cleanup redundant local ret variable assignment.
* ti,ina2xx-adc
- Use helper macro kthread_run() to replace some boilerplate.
- Avoid double reference counting.
- Drop pointless cast.
* xilinx,xadc
- Make the IRQ optional as not always wired to the host system.
* tag 'iio-for-5.17a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (103 commits)
iio: adc: ti-adc081c: Partial revert of removal of ACPI IDs
iio:addac:ad74413r: Fix uninitialized ret in a path that won't be hit.
MAINTAINERS: Add maintainer for xilinx-ams
dt-bindings: iio: adc: Add Xilinx AMS binding documentation
iio: adc: Add Xilinx AMS driver
device property: Add fwnode_iomap()
iio:accel:kxcjk-1013: Mark struct __maybe_unused to avoid warning.
iio:accel:bmc150: Mark structure __maybe_unused as only needed with for pm ops.
iio:dummy: Drop set but unused variable len.
iio:magn:ak8975: Suppress clang W=1 warning about pointer to enum conversion.
iio:imu:inv_mpu6050: Suppress clang W=1 warning about pointer to enum conversion.
iio:imu:inv_icm42600: Suppress clang W=1 warning about pointer to enum conversion.
iio:dac:mcp4725: Suppress clang W=1 warning about pointer to enum conversion.
iio:amplifiers:hmc425a: Suppress clang W=1 warning about pointer to enum conversion.
iio:adc:ti-ads1015: Suppress clang W=1 warning about pointer to enum conversion.
iio:adc:rcar: Suppress clang W=1 warning about pointer to enum conversion.
iio:adc:ina2xx-adc: Suppress clang W=1 warning about pointer to enum conversion.
iio:accel:bma180: Suppress clang W=1 warning about pointer to enum conversion.
drivers:iio:dac: Add AD3552R driver support
dt-bindings: iio: dac: Add adi,ad3552r.yaml
...
|
|
This enables use of other firmware types with minimal driver changes.
Part of an ongoing effort to move all IIO drivers over to generic
accessors in order to reduce the chance of of_* versions being
copied into new drivers. Also updated the headers to reflect this change
including using mod_devicetable.h for struct of_device_id definition
rather than going via of.h
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
|
|
Userspace tools like iio-sensor-proxy need to know the proximity level
that should be considered "near". This value is hardware-specific and
can be defined via the devicetree. Allow the driver to export the near
level.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20211125125646.54831-2-nikita@trvn.ru
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Interrupt handlers must return one of the irqreturn_t values. Returning a
error code is not supported.
The stk3310 event interrupt handler returns an error code when reading the
flags register fails.
Fix the implementation to always return an irqreturn_t value.
Fixes: 3dd477acbdd1 ("iio: light: Add threshold interrupt support for STK3310")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211024171251.22896-3-lars@metafoo.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
IIO trigger handlers need to return one of the irqreturn_t values.
Returning an error code is not supported.
The ltr501 interrupt handler gets this right for most error paths, but
there is one case where it returns the error code.
In addition for this particular case the trigger handler does not call
`iio_trigger_notify_done()`. Which when not done keeps the triggered
disabled forever.
Modify the code so that the function returns a valid irqreturn_t value as
well as calling `iio_trigger_notify_done()` on all exit paths.
Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211024171251.22896-1-lars@metafoo.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Previously ltr501 driver supported a number of light and,
proximity sensors including ltr501, ltr559 and ltr301.
This adds support for another light sensor ltr303
used in Seeed Studio reTerminal, a carrier board
for Raspberry Pi 4 CM.
Signed-off-by: Maslov Dmitry <maslovdmitry@seeed.cc>
Link: https://lore.kernel.org/r/20211106174137.6783-1-maslovdmitry@seeed.cc
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The IIO core handles a trigger ops with all NULL callbacks the
same as if the trigger ops itself was NULL.
Remove the empty trigger ops from the interrupt trigger driver to slightly
reduce the boilerplate code. Object size of the driver module is also
slightly reduced.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211031142130.20791-8-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|