iio: adis: add '__adis_enable_irq()' implementation

Add '__adis_enable_irq()' implementation which is the unlocked
version of 'adis_enable_irq()'.
Call '__adis_enable_irq()' instead of 'adis_enable_

iio: adis: add '__adis_enable_irq()' implementation

Add '__adis_enable_irq()' implementation which is the unlocked
version of 'adis_enable_irq()'.
Call '__adis_enable_irq()' instead of 'adis_enable_irq()' from
'__adis_intial_startup()' to keep the expected unlocked functionality.

This fix is needed to remove a deadlock for all devices which are
using 'adis_initial_startup()'. The deadlock occurs because the
same mutex is acquired twice, without releasing it.
The mutex is acquired once inside 'adis_initial_startup()', before
calling '__adis_initial_startup()', and once inside
'adis_enable_irq()', which is called by '__adis_initial_startup()'.
The deadlock is removed by calling '__adis_enable_irq()', instead of
'adis_enable_irq()' from within '__adis_initial_startup()'.

Fixes: b600bd7eb3335 ("iio: adis: do not disabe IRQs in 'adis_init()'")
Signed-off-by: Ramona Bolboaca <ramona.bolboaca@analog.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20221122082757.449452-2-ramona.bolboaca@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio:imu:adis: Move exports into IIO_ADISLIB namespace

In order to avoid unneessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
tha

iio:imu:adis: Move exports into IIO_ADISLIB namespace

In order to avoid unneessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the various specific device drivers that use them.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-9-jic23@kernel.org

show more ...

iio: adis: stylistic changes

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

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/2022012

iio: adis: stylistic changes

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

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

show more ...

iio: adis: handle devices that cannot unmask the drdy pin

Some devices can't mask/unmask the data ready pin and in those cases
each driver was just calling '{dis}enable_irq()' to control the trigger

iio: adis: handle devices that cannot unmask the drdy pin

Some devices can't mask/unmask the data ready pin and in those cases
each driver was just calling '{dis}enable_irq()' to control the trigger
state. This change, moves that handling into the library by introducing
a new boolean in the data structure that tells the library that the
device cannot unmask the pin.

On top of controlling the trigger state, we can also use this flag to
automatically request the IRQ with 'IRQF_NO_AUTOEN' in case it is set.
So far, all users of the library want to start operation with IRQs/DRDY
pin disabled so it should be fairly safe to do this inside the library.

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

show more ...

iio: adis: do not disabe IRQs in 'adis_init()'

With commit ecb010d441088 ("iio: imu: adis: Refactor adis_initial_startup")
we are doing a HW or SW reset to the device which means that we'll get
the

iio: adis: do not disabe IRQs in 'adis_init()'

With commit ecb010d441088 ("iio: imu: adis: Refactor adis_initial_startup")
we are doing a HW or SW reset to the device which means that we'll get
the default state of the data ready pin (which is enabled). Hence there's
no point in disabling the IRQ in the init function. Moreover, this
function is intended to initialize internal data structures and not
really do anything on the device.

As a result of this, some devices were left with the data ready pin enabled
after probe which was not the desired behavior. Thus, we move the call to
'adis_enable_irq()' to the initial startup function where it makes more
sense for it to be.

Note that for devices that cannot mask/unmask the pin, it makes no sense
to call the function at this point since the IRQ should not have been
yet requested. This will be improved in a follow up change.

Fixes: ecb010d441088 ("iio: imu: adis: Refactor adis_initial_startup")
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210903141423.517028-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: adis: do not disabe IRQs in 'adis_init()'

[ Upstream commit b600bd7eb333554518b4dd36b882b2ae58a5149e ]

With commit ecb010d441088 ("iio: imu: adis: Refactor adis_initial_startup")
we are doing

iio: adis: do not disabe IRQs in 'adis_init()'

[ Upstream commit b600bd7eb333554518b4dd36b882b2ae58a5149e ]

With commit ecb010d441088 ("iio: imu: adis: Refactor adis_initial_startup")
we are doing a HW or SW reset to the device which means that we'll get
the default state of the data ready pin (which is enabled). Hence there's
no point in disabling the IRQ in the init function. Moreover, this
function is intended to initialize internal data structures and not
really do anything on the device.

As a result of this, some devices were left with the data ready pin enabled
after probe which was not the desired behavior. Thus, we move the call to
'adis_enable_irq()' to the initial startup function where it makes more
sense for it to be.

Note that for devices that cannot mask/unmask the pin, it makes no sense
to call the function at this point since the IRQ should not have been
yet requested. This will be improved in a follow up change.

Fixes: ecb010d441088 ("iio: imu: adis: Refactor adis_initial_startup")
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210903141423.517028-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

iio: adis: set GPIO reset pin direction

Set reset pin direction to output as the reset pin needs to be an active
low output pin.

Co-developed-by: Hannu Hartikainen <hannu@hrtk.in>
Signed-off-by: Ha

iio: adis: set GPIO reset pin direction

Set reset pin direction to output as the reset pin needs to be an active
low output pin.

Co-developed-by: Hannu Hartikainen <hannu@hrtk.in>
Signed-off-by: Hannu Hartikainen <hannu@hrtk.in>
Signed-off-by: Antti Keränen <detegr@rbx.email>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Fixes: ecb010d44108 ("iio: imu: adis: Refactor adis_initial_startup")
Link: https://lore.kernel.org/r/20210708095425.13295-1-detegr@rbx.email
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: adis: Cleanout unused headers

0-day recently added the include-what-you-use header checker and
it gave a warning on an adis patch. As such I decided to
run it on all the adis drivers and see i

iio: adis: Cleanout unused headers

0-day recently added the include-what-you-use header checker and
it gave a warning on an adis patch. As such I decided to
run it on all the adis drivers and see if it made sensible suggestions.

Note this doesn't represent a complete list of what it suggested changing
as I filtered out a few on the basis they are standard headers used to
effectively include a bunch of other headers.

Could split this into a patch per driver if people prefer.

Note to anyone else trying this tool is that it is somewhat
of a loose cannon so you will be wanting to carefully check any
suggestions before proposing patches!

I thought about also reorganising the headers whilst here, but
that would make this patch harder to read, or lead to another rather
noisy patch across most of the files.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210603193616.3708447-1-jic23@kernel.org

show more ...

iio: adis: set GPIO reset pin direction

commit 7e77ef8b8d600cf8448a2bbd32f682c28884551f upstream.

Set reset pin direction to output as the reset pin needs to be an active
low output pin.

Co-develo

iio: adis: set GPIO reset pin direction

commit 7e77ef8b8d600cf8448a2bbd32f682c28884551f upstream.

Set reset pin direction to output as the reset pin needs to be an active
low output pin.

Co-developed-by: Hannu Hartikainen <hannu@hrtk.in>
Signed-off-by: Hannu Hartikainen <hannu@hrtk.in>
Signed-off-by: Antti Keränen <detegr@rbx.email>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Fixes: ecb010d44108 ("iio: imu: adis: Refactor adis_initial_startup")
Link: https://lore.kernel.org/r/20210708095425.13295-1-detegr@rbx.email
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

treewide: Use fallthrough pseudo-keyword

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through mar

treewide: Use fallthrough pseudo-keyword

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

show more ...

iio: adis: Add adis_update_bits() APIs

This patch adds a `regmap_update_bits()` like API to the ADIS library.
It provides locked and unlocked variant.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Si

iio: adis: Add adis_update_bits() APIs

This patch adds a `regmap_update_bits()` like API to the ADIS library.
It provides locked and unlocked variant.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis: Add a missing '\n' in a log message

Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'.

Fixes: 1fd456702692 ("iio: imu: adis: add support product ID check in adis_in

iio: imu: adis: Add a missing '\n' in a log message

Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'.

Fixes: 1fd456702692 ("iio: imu: adis: add support product ID check in adis_initial_startup")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis: add support product ID check in adis_initial_startup

Each driver/chip that wants to validate it's product id, can now
specify a 'prod_id_reg' and an expected 'prod_id' value.
The 'pr

iio: imu: adis: add support product ID check in adis_initial_startup

Each driver/chip that wants to validate it's product id, can now
specify a 'prod_id_reg' and an expected 'prod_id' value.
The 'prod_id' value is intentionally left 0 (uninitialized). There aren't
(yet) any product IDs with value 0; this enforces that both 'prod_id_reg'
and 'prod_id' are specified.

At the very least, this routine validates that the SPI connection to the
ADIS chip[s] works well.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis: Refactor adis_initial_startup

All the ADIS devices perform, at the beginning, a self test to make sure
the device is in a sane state. Previously, the logic was that the self-test
was

iio: imu: adis: Refactor adis_initial_startup

All the ADIS devices perform, at the beginning, a self test to make sure
the device is in a sane state. Previously, the logic was that the self-test
was performed in adis_initial_startup() and if that failed a reset was done
and then a self-test was attempted again.

This change unifies the reset mechanism under the adis_initial_startup()
call. A HW reset will be done if GPIO is configured, or a SW reset
otherwise. This should make sure that the chip is in a sane state for
self-test. Once the reset is done, the self-test operation will be
performed. If anything goes wrong with self-test, the driver should just
bail/error-out (i.e. no second attempt). The chip would likely not be a in
a sane state state if the self-test fails after a reset.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis: Add self_test_reg variable

This patch adds a dedicated self_test_reg variable. This is also a step
to let new drivers make use of `adis_initial_startup()`. Some devices
use MSG_CTRL

iio: imu: adis: Add self_test_reg variable

This patch adds a dedicated self_test_reg variable. This is also a step
to let new drivers make use of `adis_initial_startup()`. Some devices
use MSG_CTRL reg to request a self_test command while others use the
GLOB_CMD register.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis: add unlocked __adis_initial_startup()

This change splits the __adis_initial_startup() away from
adis_initial_startup(). The unlocked version can be used in certain calls
during probe

iio: imu: adis: add unlocked __adis_initial_startup()

This change splits the __adis_initial_startup() away from
adis_initial_startup(). The unlocked version can be used in certain calls
during probe, where races won't happen since the ADIS driver may not be
registered yet with IIO.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis: use new `delay` structure for SPI transfer delays

In a recent change to the SPI subsystem [1], a new `delay` struct was added
to replace the `delay_usecs`. This change replaces the c

iio: imu: adis: use new `delay` structure for SPI transfer delays

In a recent change to the SPI subsystem [1], a new `delay` struct was added
to replace the `delay_usecs`. This change replaces the current `delay_usecs`
with `delay` for this driver.

The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure
that both `delay_usecs` & `delay` are used (in this order to preserve
backwards compatibility).

[1] commit bebcfd272df6485 ("spi: introduce `delay` field for
`spi_transfer` + spi_transfer_delay_exec()")

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: adis: Introduce timeouts structure

The adis library only allows to define a `startup_delay` which for some
devices is enough. However, other devices define different timeouts with
significantly

iio: adis: Introduce timeouts structure

The adis library only allows to define a `startup_delay` which for some
devices is enough. However, other devices define different timeouts with
significantly different timings which could lead to devices to not wait
enough time or to wait a lot more than necessary (which is not
efficient). This patch introduces a new timeout struct that must be
passed into `adis_init()`. There are mainly, for now, three timeouts
used. This is also an introductory patch with the goal of refactoring
`adis_initial_startup()`. New driver's (eg: adis16480, adis16460) are
replicating code for the device initial setup. With some changes (being
this the first one) we can pass this to `adis_initial_startup()`.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis: group single conversion under a single state lock

The single conversion function does a series of reads + writes. This change
extends the use of the state_lock for the entire set of

iio: imu: adis: group single conversion under a single state lock

The single conversion function does a series of reads + writes. This change
extends the use of the state_lock for the entire set of operations.
Previously, indio_dev's mlock was used. This change also removes the use of
this lock.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis: protect initial startup routine with state lock

The initial startup routine is called by some ADIS drivers during probe,
and before registering with IIO. Normally, userspace should n

iio: imu: adis: protect initial startup routine with state lock

The initial startup routine is called by some ADIS drivers during probe,
and before registering with IIO. Normally, userspace should not be able to
do any access to the device (as there shouldn't be any available).

This change extends the state lock to the entire initial-startup routine.
Behaviourally nothing should change, but this should make the library
function a bit more robust.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis: create an unlocked version of adis_reset()

The reset routine may also be important to be protected by the state-lock
and grouped with other operations, so create an unlocked version,

iio: imu: adis: create an unlocked version of adis_reset()

The reset routine may also be important to be protected by the state-lock
and grouped with other operations, so create an unlocked version, so that
this can be done.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis: create an unlocked version of adis_check_status()

This one also gets re-used in certain operations, so it makes sense to
have an unlocked version of this to group it with other
reads

iio: imu: adis: create an unlocked version of adis_check_status()

This one also gets re-used in certain operations, so it makes sense to
have an unlocked version of this to group it with other
reads/writes/operations to have a single lock for the whole state change.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis[16480]: group RW into a single lock in adis_enable_irq()

The adis_enable_irq() does a read & a write. This change keeps a lock for
the duration of both operations vs for each op.

The

iio: imu: adis[16480]: group RW into a single lock in adis_enable_irq()

The adis_enable_irq() does a read & a write. This change keeps a lock for
the duration of both operations vs for each op.

The change is also needed in adis16480, since that has it's own
implementation for adis_enable_irq().

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis: add unlocked read/write function versions

This will allow more flexible control to group reads & writes into a single
lock (particularly the state_lock).

The end-goal is to remove t

iio: imu: adis: add unlocked read/write function versions

This will allow more flexible control to group reads & writes into a single
lock (particularly the state_lock).

The end-goal is to remove the indio_dev->mlock usage, and the simplest fix
would have been to just add another lock, which would not be a good idea on
the long-run.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: imu: adis: rename txrx_lock -> state_lock

The lock can be extended a bit to protect other elements that are not
particular to just TX/RX. Another idea would have been to just add a new
`state_l

iio: imu: adis: rename txrx_lock -> state_lock

The lock can be extended a bit to protect other elements that are not
particular to just TX/RX. Another idea would have been to just add a new
`state_lock`, but that would mean 2 locks which would be redundant, and
probably cause more potential for dead-locks.

What will be done in the next patches, will be to add some unlocked
versions for read/write_reg functions.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...