linux-stable.git/include/linux/iio, branch v5.18.18

iio: cros: Register FIFO callback after sensor is registered

2022-08-17T12:41:50+00:00

[ Upstream commit 0b4ae3f6d1210c11f9baf159009c7227eacf90f2 ]

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 
Signed-off-by: Gwendal Grignou 
Reviewed-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20220711144716.642617-1-gwendal@chromium.org
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin

iio: core: Fix IIO_ALIGN and rename as it was not sufficiently large

2022-08-17T12:41:23+00:00

[ Upstream commit 12c4efe3509b8018e76ea3ebda8227cb53bf5887 ]

Discussion of the series:
https://lore.kernel.org/all/20220405135758.774016-1-catalin.marinas@arm.com/
mm, arm64: Reduce ARCH_KMALLOC_MINALIGN brought to my attention that
our current IIO usage of L1CACHE_ALIGN is insufficient as their are Arm
platforms out their with non coherent DMA and larger cache lines at
at higher levels of their cache hierarchy.

Rename the define to make it's purpose more explicit. It will be used
much more widely going forwards (to replace incorrect ____cacheline_aligned
markings.

Note this patch will greatly reduce the padding on some architectures
that have smaller requirements for DMA safe buffers.

The history of changing values of ARCH_KMALLOC_MINALIGN via
ARCH_DMA_MINALIGN on arm64 is rather complex. I'm not tagging this
as fixing a particular patch from that route as it's not clear what to tag.

Most recently a change to bring them back inline was reverted because
of some Qualcomm Kryo cores with an L2 cache with 128-byte lines
sitting above the point of coherency.

c1132702c71f Revert "arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"
That reverts:
65688d2a05de arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES) which
refers to the change originally being motivated by Thunder x1 performance
rather than correctness.

Fixes: 6f7c8ee585e9d ("staging:iio: Add ability to allocate private data space to iio_allocate_device")
Signed-off-by: Jonathan Cameron 
Acked-by: Nuno Sá 
Link: https://lore.kernel.org/r/20220508175712.647246-2-jic23@kernel.org
Signed-off-by: Sasha Levin

iio: st_sensors: Add a local lock for protecting odr

2022-06-14T16:45:08+00:00

[ Upstream commit 474010127e2505fc463236470908e1ff5ddb3578 ]

Right now the (framework) mlock lock is (ab)used for multiple purposes:
1- protecting concurrent accesses over the odr local cache
2- avoid changing samplig frequency whilst buffer is running

Let's start by handling situation #1 with a local lock.

Suggested-by: Jonathan Cameron 
Cc: Denis Ciocca 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/r/20220207143840.707510-7-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin

iio: afe: rescale: add offset support

2022-02-27T13:38:10+00:00

This is a preparatory change required for the addition of temperature
sensing front ends.

Signed-off-by: Liam Beguin 
Reviewed-by: Peter Rosin 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220213025739.2561834-4-liambeguin@gmail.com
Signed-off-by: Jonathan Cameron

iio: afe: rescale: expose scale processing function

2022-02-27T13:37:49+00:00

In preparation for the addition of kunit tests, expose the logic
responsible for combining channel scales.

Signed-off-by: Liam Beguin 
Reviewed-by: Peter Rosin 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220213025739.2561834-2-liambeguin@gmail.com
Signed-off-by: Jonathan Cameron

iio: adc: qcom-vadc-common: Re-use generic struct u32_fract

2022-01-30T12:21:25+00:00

Instead of custom data type re-use generic struct u32_fract.
No changes intended.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220126135353.24007-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron

iio: adis: stylistic changes

2022-01-23T18:03:37+00:00

Minor stylistic changes to address checkptach complains when called with
'--strict'.

Signed-off-by: Nuno Sá 
Link: https://lore.kernel.org/r/20220122130905.99-3-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron

adis: simplify 'adis_update_bits' macros

2022-01-23T18:03:37+00:00

There's no need to use  '__builtin_choose_expr' to choose the right
call to 'adis_update_bits_base()'. We can change the 'BUILD_BUG_ON()'
condition so that it makes sure only the supported sizes are
passed in. With that, we can just use 'sizeof(val)' as the size argument
of 'adis_update_bits_base()'.

Signed-off-by: Nuno Sá 
Link: https://lore.kernel.org/r/20220122130905.99-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron

iio: core: Fix the kernel doc regarding the currentmode iio_dev entry

2022-01-23T18:03:35+00:00

This is an internal variable, which should be accessed in a very
sporadic way and in no case changed by any device driver.

Signed-off-by: Miquel Raynal 
Reviewed-by: Alexandru Ardelean 
Link: https://lore.kernel.org/r/20211215151344.163036-2-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron

iio: trigger: Fix a scheduling whilst atomic issue seen on tsc2046

2021-12-12T17:12:18+00:00

IIO triggers are software IRQ chips that split an incoming IRQ into
separate IRQs routed to all devices using the trigger.
When all consumers are done then a trigger callback reenable() is
called.  There are a few circumstances under which this can happen
in atomic context.

1) A single user of the trigger that calls the iio_trigger_done()
function from interrupt context.
2) A race between disconnecting the last device from a trigger and
the trigger itself sucessfully being disabled.

To avoid a resulting scheduling whilst atomic, close this second corner
by using schedule_work() to ensure the reenable is not done in atomic
context.

Note that drivers must be careful to manage the interaction of
set_state() and reenable() callbacks to ensure appropriate reference
counting if they are relying on the same hardware controls.

Deliberately taking this the slow path rather than via a fixes tree
because the error has hard to hit and I would like it to soak for a while
before hitting a release kernel.

Signed-off-by: Jonathan Cameron 
Cc: Pengutronix Kernel Team 
Cc: Dmitry Torokhov 
Tested-by: Oleksij Rempel 
Cc: 
Link: https://lore.kernel.org/r/20211017172209.112387-1-jic23@kernel.org