kernel/linux.git/include/linux/iio/trigger.h, branch v6.19.11

iio: trigger: Add simple trigger_validation helper

2023-05-23T20:20:17+00:00

Some triggers can only be attached to the IIO device that corresponds to the same physical device. Implement generic helper which can be used as a validate_trigger callback for such devices. Suggested-by: Jonathan Cameron Signed-off-by: Matti Vaittinen Link: https://lore.kernel.org/r/51cd3e3e74a6addf8d333f4a109fb9c5a11086ee.1683541225.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron

iio: Rename iio_trigger_poll_chained and add kernel-doc

2023-03-11T12:18:29+00:00

Rename the function to iio_trigger_poll_nested. Add kernel-doc with a note on the context where the function is expected to be called. Signed-off-by: Mehdi Djait Link: https://lore.kernel.org/r/841b533cba28ca25a8e87280c44e45979166e8e2.1677761379.git.mehdi.djait.k@gmail.com Signed-off-by: Jonathan Cameron

iio: Improve the kernel-doc of iio_trigger_poll

2023-03-11T12:18:29+00:00

Move the kernel-doc of the function to industrialio-trigger.c Add a note on the context where the function is expected to be called. Signed-off-by: Mehdi Djait Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/bd84fc17e9d22eab998bf48720297f9a77689f45.1677761379.git.mehdi.djait.k@gmail.com Signed-off-by: Jonathan Cameron

iio: trigger: move trig->owner init to trigger allocate() stage

2022-07-16T15:24:19+00:00

To provide a new IIO trigger to the IIO core, usually driver executes the following pipeline: allocate()/register()/get(). Before, IIO core assigned trig->owner as a pointer to the module which registered this trigger at the register() stage. But actually the trigger object is owned by the module earlier, on the allocate() stage, when trigger object is successfully allocated for the driver. This patch moves trig->owner initialization from register() stage of trigger initialization pipeline to allocate() stage to eliminate all misunderstandings and time gaps between trigger object creation and owner acquiring. Signed-off-by: Dmitry Rokosov Link: https://lore.kernel.org/r/20220601174837.20292-1-ddrokosov@sberdevices.ru Signed-off-by: Jonathan Cameron

iio: trigger: warn about non-registered iio trigger getting attempt

2022-06-18T13:26:17+00:00

As a part of patch series about wrong trigger register() and get() calls order in the some IIO drivers trigger initialization path: https://lore.kernel.org/all/20220524181150.9240-1-ddrokosov@sberdevices.ru/ runtime WARN_ONCE() is added to alarm IIO driver authors who make such a mistake. When an IIO driver allocates a new IIO trigger, it should register it before calling the get() operation. In other words, each IIO driver must abide by IIO trigger alloc()/register()/get() calls order. Signed-off-by: Dmitry Rokosov Link: https://lore.kernel.org/r/20220607183907.20017-1-ddrokosov@sberdevices.ru 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

iio: set default trig->dev.parent

2021-03-25T19:13:50+00:00

When allocated with [devm_]iio_trigger_alloc(), set trig device parent to the device the trigger is allocated for by default. It can always be reassigned in the probe routine. Change iio_trigger_alloc() API to add the device pointer to be coherent with devm_iio_trigger_alloc, using similar interface to iio_device_alloc(). Signed-off-by: Gwendal Grignou Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210309193620.2176163-2-gwendal@chromium.org Signed-off-by: Jonathan Cameron

iio:trigger: rename try_reenable() to reenable() plus return void

2020-12-03T19:40:26+00:00

As we no longer support a try again if we cannot reenable the trigger rename the function to reflect this. Also we don't do anything with the value returned so stop it returning anything. For the few drivers that didn't already print an error message in this patch, add such a print. Signed-off-by: Jonathan Cameron Reviewed-by: Lars-Peter Clausen Acked-by: Linus Walleij Acked-by: Srinivas Pandruvada Cc: Linus Walleij Cc: Srinivas Pandruvada Cc: Christian Oder Cc: Eugen Hristev Cc: Nishant Malpani Cc: Daniel Baluta Link: https://lore.kernel.org/r/20200920132548.196452-3-jic23@kernel.org

iio: fix a kernel-doc markup

2020-10-31T15:02:36+00:00

A function has a different name between their prototype and its kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/46622c3bdcffb76e79719f0fe5011c2952960b32.1603469755.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Cameron

iio: core: drop devm_iio_trigger_unregister() API call

2020-04-19T15:56:36+00:00

It's unused so far, so it can be removed. Also makes sense to remove it to discourage weird uses of this call during review. Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron