Passing IRQF_ONESHOT ensures that the interrupt source is masked until
the secondary (threaded) handler is done. If only a primary handler is
used then the flag makes no sense because the interrupt can not fire
(again) while its handler is running.
The flag also disallows force-threading of the primary handler and the
irq-core will warn about this.
The intention here was probably not allowing forced-threading for
handlers such as iio_trigger_generic_data_rdy_poll() will intends to
invoke hard-interrupt handlers.
Replace IRQF_ONESHOT with IRQF_NO_THREAD.
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Puranjay Mohan <puranjay@kernel.org>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Marcelo Schmitt <marcelo.schmitt@analog.com>
Cc: Marcus Folkesson <marcus.folkesson@gmail.com>
Cc: Kent Gustavsson <kent@minoris.se>
Cc: Gustavo Silva <gustavograzs@gmail.com>
Cc: Nishant Malpani <nish.malpani25@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/iio/accel/adxl355_core.c | 3 ++-
drivers/iio/accel/adxl372.c | 9 ++++-----
drivers/iio/accel/mxc4005.c | 11 ++++-------
drivers/iio/accel/stk8ba50.c | 11 ++++-------
drivers/iio/adc/ad4170-4.c | 2 +-
drivers/iio/adc/ad7768-1.c | 5 ++---
drivers/iio/adc/ad7779.c | 2 +-
drivers/iio/adc/mcp3911.c | 2 +-
drivers/iio/adc/ti-ads131e08.c | 2 +-
drivers/iio/chemical/ens160_core.c | 9 +++------
drivers/iio/gyro/adxrs290.c | 2 +-
drivers/iio/health/afe4403.c | 9 ++++-----
drivers/iio/health/afe4404.c | 9 ++++-----
drivers/iio/magnetometer/bmc150_magn.c | 9 +++------
drivers/iio/pressure/dlhl60d.c | 6 +++---
drivers/iio/temperature/tmp006.c | 10 ++++------
16 files changed, 42 insertions(+), 59 deletions(-)
diff --git a/drivers/iio/accel/adxl355_core.c b/drivers/iio/accel/adxl355_core.c
index 5fc7f814b9077..04caa493176d3 100644
--- a/drivers/iio/accel/adxl355_core.c
+++ b/drivers/iio/accel/adxl355_core.c
@@ -770,7 +770,8 @@ static int adxl355_probe_trigger(struct iio_dev *indio_dev, int irq)
ret = devm_request_irq(data->dev, irq,
&iio_trigger_generic_data_rdy_poll,
- IRQF_ONESHOT, "adxl355_irq", data->dready_trig);
+ IRQF_NO_THREAD,
+ "adxl355_irq", data->dready_trig);
if (ret)
return dev_err_probe(data->dev, ret, "request irq %d failed\n",
irq);
diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
index 46d518a2a0291..2f6aa52aeba51 100644
--- a/drivers/iio/accel/adxl372.c
+++ b/drivers/iio/accel/adxl372.c
@@ -1247,11 +1247,10 @@ int adxl372_probe(struct device *dev, struct regmap *regmap,
indio_dev->trig = iio_trigger_get(st->dready_trig);
- ret = devm_request_threaded_irq(dev, st->irq,
- iio_trigger_generic_data_rdy_poll,
- NULL,
- IRQF_TRIGGER_RISING | IRQF_ONESHOT,
- indio_dev->name, st->dready_trig);
+ ret = devm_request_irq(dev, st->irq,
+ iio_trigger_generic_data_rdy_poll,
+ IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
+ indio_dev->name, st->dready_trig);
if (ret < 0)
return ret;
}
diff --git a/drivers/iio/accel/mxc4005.c b/drivers/iio/accel/mxc4005.c
index ac973d871c8bb..a2c3cf13d0981 100644
--- a/drivers/iio/accel/mxc4005.c
+++ b/drivers/iio/accel/mxc4005.c
@@ -486,13 +486,10 @@ static int mxc4005_probe(struct i2c_client *client)
if (!data->dready_trig)
return -ENOMEM;
- ret = devm_request_threaded_irq(&client->dev, client->irq,
- iio_trigger_generic_data_rdy_poll,
- NULL,
- IRQF_TRIGGER_FALLING |
- IRQF_ONESHOT,
- "mxc4005_event",
- data->dready_trig);
+ ret = devm_request_irq(&client->dev, client->irq,
+ iio_trigger_generic_data_rdy_poll,
+ IRQF_TRIGGER_FALLING | IRQF_NO_THREAD,
+ "mxc4005_event", data->dready_trig);
if (ret) {
dev_err(&client->dev,
"failed to init threaded irq\n");
diff --git a/drivers/iio/accel/stk8ba50.c b/drivers/iio/accel/stk8ba50.c
index 384f1fbcbcb37..a9ff2a273fe1c 100644
--- a/drivers/iio/accel/stk8ba50.c
+++ b/drivers/iio/accel/stk8ba50.c
@@ -428,13 +428,10 @@ static int stk8ba50_probe(struct i2c_client *client)
}
if (client->irq > 0) {
- ret = devm_request_threaded_irq(&client->dev, client->irq,
- stk8ba50_data_rdy_trig_poll,
- NULL,
- IRQF_TRIGGER_RISING |
- IRQF_ONESHOT,
- "stk8ba50_event",
- indio_dev);
+ ret = devm_request_irq(&client->dev, client->irq,
+ stk8ba50_data_rdy_trig_poll,
+ IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
+ "stk8ba50_event", indio_dev);
if (ret < 0) {
dev_err(&client->dev, "request irq %d failed\n",
client->irq);
diff --git a/drivers/iio/adc/ad4170-4.c b/drivers/iio/adc/ad4170-4.c
index efaed92191f1b..82205bfae531e 100644
--- a/drivers/iio/adc/ad4170-4.c
+++ b/drivers/iio/adc/ad4170-4.c
@@ -2973,7 +2973,7 @@ static int ad4170_probe(struct spi_device *spi)
if (spi->irq) {
ret = devm_request_irq(dev, spi->irq, &ad4170_irq_handler,
- IRQF_ONESHOT, indio_dev->name, indio_dev);
+ IRQF_NO_THREAD, indio_dev->name, indio_dev);
if (ret)
return ret;
diff --git a/drivers/iio/adc/ad7768-1.c b/drivers/iio/adc/ad7768-1.c
index d96802b7847a6..84ce23c8e5782 100644
--- a/drivers/iio/adc/ad7768-1.c
+++ b/drivers/iio/adc/ad7768-1.c
@@ -1394,9 +1394,8 @@ static int ad7768_probe(struct spi_device *spi)
if (ret)
return ret;
- ret = devm_request_irq(&spi->dev, spi->irq,
- &ad7768_interrupt,
- IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ ret = devm_request_irq(&spi->dev, spi->irq, &ad7768_interrupt,
+ IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
indio_dev->name, indio_dev);
if (ret)
return ret;
diff --git a/drivers/iio/adc/ad7779.c b/drivers/iio/adc/ad7779.c
index aac5049c9a07b..695cc79e78da5 100644
--- a/drivers/iio/adc/ad7779.c
+++ b/drivers/iio/adc/ad7779.c
@@ -840,7 +840,7 @@ static int ad7779_setup_without_backend(struct ad7779_state *st, struct iio_dev
iio_trigger_set_drvdata(st->trig, st);
ret = devm_request_irq(dev, st->spi->irq, iio_trigger_generic_data_rdy_poll,
- IRQF_ONESHOT | IRQF_NO_AUTOEN, indio_dev->name,
+ IRQF_NO_THREAD | IRQF_NO_AUTOEN, indio_dev->name,
st->trig);
if (ret)
return dev_err_probe(dev, ret, "request IRQ %d failed\n",
diff --git a/drivers/iio/adc/mcp3911.c b/drivers/iio/adc/mcp3911.c
index a6f21791c6859..ddc3721f3f688 100644
--- a/drivers/iio/adc/mcp3911.c
+++ b/drivers/iio/adc/mcp3911.c
@@ -815,7 +815,7 @@ static int mcp3911_probe(struct spi_device *spi)
* don't enable the interrupt to avoid extra load on the system.
*/
ret = devm_request_irq(dev, spi->irq, &iio_trigger_generic_data_rdy_poll,
- IRQF_NO_AUTOEN | IRQF_ONESHOT,
+ IRQF_NO_AUTOEN | IRQF_NO_THREAD,
indio_dev->name, adc->trig);
if (ret)
return ret;
diff --git a/drivers/iio/adc/ti-ads131e08.c b/drivers/iio/adc/ti-ads131e08.c
index c9a20024d6b11..a585621b0bc30 100644
--- a/drivers/iio/adc/ti-ads131e08.c
+++ b/drivers/iio/adc/ti-ads131e08.c
@@ -827,7 +827,7 @@ static int ads131e08_probe(struct spi_device *spi)
if (spi->irq) {
ret = devm_request_irq(&spi->dev, spi->irq,
ads131e08_interrupt,
- IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ IRQF_TRIGGER_FALLING | IRQF_NO_THREAD,
spi->dev.driver->name, indio_dev);
if (ret)
return dev_err_probe(&spi->dev, ret,
diff --git a/drivers/iio/chemical/ens160_core.c b/drivers/iio/chemical/ens160_core.c
index 86bde4a91bf7e..bbc96c4c62838 100644
--- a/drivers/iio/chemical/ens160_core.c
+++ b/drivers/iio/chemical/ens160_core.c
@@ -316,12 +316,9 @@ static int ens160_setup_trigger(struct iio_dev *indio_dev, int irq)
indio_dev->trig = iio_trigger_get(trig);
- ret = devm_request_threaded_irq(dev, irq,
- iio_trigger_generic_data_rdy_poll,
- NULL,
- IRQF_ONESHOT,
- indio_dev->name,
- indio_dev->trig);
+ ret = devm_request_irq(dev, irq, iio_trigger_generic_data_rdy_poll,
+ IRQF_NO_THREAD, indio_dev->name,
+ indio_dev->trig);
if (ret)
return dev_err_probe(dev, ret, "failed to request irq\n");
diff --git a/drivers/iio/gyro/adxrs290.c b/drivers/iio/gyro/adxrs290.c
index 8fcb41f45baac..3efe385ebedc4 100644
--- a/drivers/iio/gyro/adxrs290.c
+++ b/drivers/iio/gyro/adxrs290.c
@@ -597,7 +597,7 @@ static int adxrs290_probe_trigger(struct iio_dev *indio_dev)
ret = devm_request_irq(&st->spi->dev, st->spi->irq,
&iio_trigger_generic_data_rdy_poll,
- IRQF_ONESHOT, "adxrs290_irq", st->dready_trig);
+ IRQF_NO_THREAD, "adxrs290_irq", st->dready_trig);
if (ret < 0)
return dev_err_probe(&st->spi->dev, ret,
"request irq %d failed\n", st->spi->irq);
diff --git a/drivers/iio/health/afe4403.c b/drivers/iio/health/afe4403.c
index 0e5a512e3bb8f..d358f4d5e5da8 100644
--- a/drivers/iio/health/afe4403.c
+++ b/drivers/iio/health/afe4403.c
@@ -540,11 +540,10 @@ static int afe4403_probe(struct spi_device *spi)
return ret;
}
- ret = devm_request_threaded_irq(dev, afe->irq,
- iio_trigger_generic_data_rdy_poll,
- NULL, IRQF_ONESHOT,
- AFE4403_DRIVER_NAME,
- afe->trig);
+ ret = devm_request_irq(dev, afe->irq,
+ iio_trigger_generic_data_rdy_poll,
+ IRQF_NO_THREAD, AFE4403_DRIVER_NAME,
+ afe->trig);
if (ret) {
dev_err(dev, "Unable to request IRQ\n");
return ret;
diff --git a/drivers/iio/health/afe4404.c b/drivers/iio/health/afe4404.c
index 768d794e574b9..032da52a96d0e 100644
--- a/drivers/iio/health/afe4404.c
+++ b/drivers/iio/health/afe4404.c
@@ -547,11 +547,10 @@ static int afe4404_probe(struct i2c_client *client)
return ret;
}
- ret = devm_request_threaded_irq(dev, afe->irq,
- iio_trigger_generic_data_rdy_poll,
- NULL, IRQF_ONESHOT,
- AFE4404_DRIVER_NAME,
- afe->trig);
+ ret = devm_request_irq(dev, afe->irq,
+ iio_trigger_generic_data_rdy_poll,
+ IRQF_NO_THREAD, AFE4404_DRIVER_NAME,
+ afe->trig);
if (ret) {
dev_err(dev, "Unable to request IRQ\n");
return ret;
diff --git a/drivers/iio/magnetometer/bmc150_magn.c b/drivers/iio/magnetometer/bmc150_magn.c
index 6a73f6e2f1f06..a022e1805dff7 100644
--- a/drivers/iio/magnetometer/bmc150_magn.c
+++ b/drivers/iio/magnetometer/bmc150_magn.c
@@ -906,12 +906,9 @@ int bmc150_magn_probe(struct device *dev, struct regmap *regmap,
goto err_poweroff;
}
- ret = request_threaded_irq(irq,
- iio_trigger_generic_data_rdy_poll,
- NULL,
- IRQF_TRIGGER_RISING | IRQF_ONESHOT,
- "bmc150_magn_event",
- data->dready_trig);
+ ret = request_irq(irq, iio_trigger_generic_data_rdy_poll,
+ IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
+ "bmc150_magn_event", data->dready_trig);
if (ret < 0) {
dev_err(dev, "request irq %d failed\n", irq);
goto err_trigger_unregister;
diff --git a/drivers/iio/pressure/dlhl60d.c b/drivers/iio/pressure/dlhl60d.c
index 8bad7162fec64..e975b733ce0a1 100644
--- a/drivers/iio/pressure/dlhl60d.c
+++ b/drivers/iio/pressure/dlhl60d.c
@@ -306,9 +306,9 @@ static int dlh_probe(struct i2c_client *client)
indio_dev->num_channels = ARRAY_SIZE(dlh_channels);
if (client->irq > 0) {
- ret = devm_request_threaded_irq(&client->dev, client->irq,
- dlh_interrupt, NULL,
- IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ ret = devm_request_irq(&client->dev, client->irq,
+ dlh_interrupt,
+ IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
st->info->name, indio_dev);
if (ret) {
dev_err(&client->dev, "failed to allocate threaded irq");
diff --git a/drivers/iio/temperature/tmp006.c b/drivers/iio/temperature/tmp006.c
index 10bd3f221929d..d8d8c8936d177 100644
--- a/drivers/iio/temperature/tmp006.c
+++ b/drivers/iio/temperature/tmp006.c
@@ -356,12 +356,10 @@ static int tmp006_probe(struct i2c_client *client)
indio_dev->trig = iio_trigger_get(data->drdy_trig);
- ret = devm_request_threaded_irq(&client->dev, client->irq,
- iio_trigger_generic_data_rdy_poll,
- NULL,
- IRQF_ONESHOT,
- "tmp006_irq",
- data->drdy_trig);
+ ret = devm_request_irq(&client->dev, client->irq,
+ iio_trigger_generic_data_rdy_poll,
+ IRQF_NO_THREAD, "tmp006_irq",
+ data->drdy_trig);
if (ret < 0)
return ret;
}
--
2.51.0On Fri, 2026-01-23 at 12:37 +0100, Sebastian Andrzej Siewior wrote:
> Passing IRQF_ONESHOT ensures that the interrupt source is masked until
> the secondary (threaded) handler is done. If only a primary handler is
> used then the flag makes no sense because the interrupt can not fire
> (again) while its handler is running.
> The flag also disallows force-threading of the primary handler and the
> irq-core will warn about this.
>
> The intention here was probably not allowing forced-threading for
> handlers such as iio_trigger_generic_data_rdy_poll() will intends to
> invoke hard-interrupt handlers.
>
> Replace IRQF_ONESHOT with IRQF_NO_THREAD.
>
> Cc: Lars-Peter Clausen <lars@metafoo.de>
> Cc: Michael Hennerich <Michael.Hennerich@analog.com>
> Cc: Puranjay Mohan <puranjay@kernel.org>
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: Marcelo Schmitt <marcelo.schmitt@analog.com>
> Cc: Marcus Folkesson <marcus.folkesson@gmail.com>
> Cc: Kent Gustavsson <kent@minoris.se>
> Cc: Gustavo Silva <gustavograzs@gmail.com>
> Cc: Nishant Malpani <nish.malpani25@gmail.com>
> Cc: linux-iio@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
LGTM,
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
> drivers/iio/accel/adxl355_core.c | 3 ++-
> drivers/iio/accel/adxl372.c | 9 ++++-----
> drivers/iio/accel/mxc4005.c | 11 ++++-------
> drivers/iio/accel/stk8ba50.c | 11 ++++-------
> drivers/iio/adc/ad4170-4.c | 2 +-
> drivers/iio/adc/ad7768-1.c | 5 ++---
> drivers/iio/adc/ad7779.c | 2 +-
> drivers/iio/adc/mcp3911.c | 2 +-
> drivers/iio/adc/ti-ads131e08.c | 2 +-
> drivers/iio/chemical/ens160_core.c | 9 +++------
> drivers/iio/gyro/adxrs290.c | 2 +-
> drivers/iio/health/afe4403.c | 9 ++++-----
> drivers/iio/health/afe4404.c | 9 ++++-----
> drivers/iio/magnetometer/bmc150_magn.c | 9 +++------
> drivers/iio/pressure/dlhl60d.c | 6 +++---
> drivers/iio/temperature/tmp006.c | 10 ++++------
> 16 files changed, 42 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl355_core.c b/drivers/iio/accel/adxl355_core.c
> index 5fc7f814b9077..04caa493176d3 100644
> --- a/drivers/iio/accel/adxl355_core.c
> +++ b/drivers/iio/accel/adxl355_core.c
> @@ -770,7 +770,8 @@ static int adxl355_probe_trigger(struct iio_dev *indio_dev, int irq)
>
> ret = devm_request_irq(data->dev, irq,
> &iio_trigger_generic_data_rdy_poll,
> - IRQF_ONESHOT, "adxl355_irq", data->dready_trig);
> + IRQF_NO_THREAD,
> + "adxl355_irq", data->dready_trig);
> if (ret)
> return dev_err_probe(data->dev, ret, "request irq %d failed\n",
> irq);
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index 46d518a2a0291..2f6aa52aeba51 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -1247,11 +1247,10 @@ int adxl372_probe(struct device *dev, struct regmap *regmap,
>
> indio_dev->trig = iio_trigger_get(st->dready_trig);
>
> - ret = devm_request_threaded_irq(dev, st->irq,
> - iio_trigger_generic_data_rdy_poll,
> - NULL,
> - IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> - indio_dev->name, st->dready_trig);
> + ret = devm_request_irq(dev, st->irq,
> + iio_trigger_generic_data_rdy_poll,
> + IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> + indio_dev->name, st->dready_trig);
> if (ret < 0)
> return ret;
> }
> diff --git a/drivers/iio/accel/mxc4005.c b/drivers/iio/accel/mxc4005.c
> index ac973d871c8bb..a2c3cf13d0981 100644
> --- a/drivers/iio/accel/mxc4005.c
> +++ b/drivers/iio/accel/mxc4005.c
> @@ -486,13 +486,10 @@ static int mxc4005_probe(struct i2c_client *client)
> if (!data->dready_trig)
> return -ENOMEM;
>
> - ret = devm_request_threaded_irq(&client->dev, client->irq,
> - iio_trigger_generic_data_rdy_poll,
> - NULL,
> - IRQF_TRIGGER_FALLING |
> - IRQF_ONESHOT,
> - "mxc4005_event",
> - data->dready_trig);
> + ret = devm_request_irq(&client->dev, client->irq,
> + iio_trigger_generic_data_rdy_poll,
> + IRQF_TRIGGER_FALLING | IRQF_NO_THREAD,
> + "mxc4005_event", data->dready_trig);
> if (ret) {
> dev_err(&client->dev,
> "failed to init threaded irq\n");
> diff --git a/drivers/iio/accel/stk8ba50.c b/drivers/iio/accel/stk8ba50.c
> index 384f1fbcbcb37..a9ff2a273fe1c 100644
> --- a/drivers/iio/accel/stk8ba50.c
> +++ b/drivers/iio/accel/stk8ba50.c
> @@ -428,13 +428,10 @@ static int stk8ba50_probe(struct i2c_client *client)
> }
>
> if (client->irq > 0) {
> - ret = devm_request_threaded_irq(&client->dev, client->irq,
> - stk8ba50_data_rdy_trig_poll,
> - NULL,
> - IRQF_TRIGGER_RISING |
> - IRQF_ONESHOT,
> - "stk8ba50_event",
> - indio_dev);
> + ret = devm_request_irq(&client->dev, client->irq,
> + stk8ba50_data_rdy_trig_poll,
> + IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> + "stk8ba50_event", indio_dev);
> if (ret < 0) {
> dev_err(&client->dev, "request irq %d failed\n",
> client->irq);
> diff --git a/drivers/iio/adc/ad4170-4.c b/drivers/iio/adc/ad4170-4.c
> index efaed92191f1b..82205bfae531e 100644
> --- a/drivers/iio/adc/ad4170-4.c
> +++ b/drivers/iio/adc/ad4170-4.c
> @@ -2973,7 +2973,7 @@ static int ad4170_probe(struct spi_device *spi)
>
> if (spi->irq) {
> ret = devm_request_irq(dev, spi->irq, &ad4170_irq_handler,
> - IRQF_ONESHOT, indio_dev->name, indio_dev);
> + IRQF_NO_THREAD, indio_dev->name, indio_dev);
> if (ret)
> return ret;
>
> diff --git a/drivers/iio/adc/ad7768-1.c b/drivers/iio/adc/ad7768-1.c
> index d96802b7847a6..84ce23c8e5782 100644
> --- a/drivers/iio/adc/ad7768-1.c
> +++ b/drivers/iio/adc/ad7768-1.c
> @@ -1394,9 +1394,8 @@ static int ad7768_probe(struct spi_device *spi)
> if (ret)
> return ret;
>
> - ret = devm_request_irq(&spi->dev, spi->irq,
> - &ad7768_interrupt,
> - IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> + ret = devm_request_irq(&spi->dev, spi->irq, &ad7768_interrupt,
> + IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> indio_dev->name, indio_dev);
> if (ret)
> return ret;
> diff --git a/drivers/iio/adc/ad7779.c b/drivers/iio/adc/ad7779.c
> index aac5049c9a07b..695cc79e78da5 100644
> --- a/drivers/iio/adc/ad7779.c
> +++ b/drivers/iio/adc/ad7779.c
> @@ -840,7 +840,7 @@ static int ad7779_setup_without_backend(struct ad7779_state *st, struct
> iio_dev
> iio_trigger_set_drvdata(st->trig, st);
>
> ret = devm_request_irq(dev, st->spi->irq, iio_trigger_generic_data_rdy_poll,
> - IRQF_ONESHOT | IRQF_NO_AUTOEN, indio_dev->name,
> + IRQF_NO_THREAD | IRQF_NO_AUTOEN, indio_dev->name,
> st->trig);
> if (ret)
> return dev_err_probe(dev, ret, "request IRQ %d failed\n",
> diff --git a/drivers/iio/adc/mcp3911.c b/drivers/iio/adc/mcp3911.c
> index a6f21791c6859..ddc3721f3f688 100644
> --- a/drivers/iio/adc/mcp3911.c
> +++ b/drivers/iio/adc/mcp3911.c
> @@ -815,7 +815,7 @@ static int mcp3911_probe(struct spi_device *spi)
> * don't enable the interrupt to avoid extra load on the system.
> */
> ret = devm_request_irq(dev, spi->irq, &iio_trigger_generic_data_rdy_poll,
> - IRQF_NO_AUTOEN | IRQF_ONESHOT,
> + IRQF_NO_AUTOEN | IRQF_NO_THREAD,
> indio_dev->name, adc->trig);
> if (ret)
> return ret;
> diff --git a/drivers/iio/adc/ti-ads131e08.c b/drivers/iio/adc/ti-ads131e08.c
> index c9a20024d6b11..a585621b0bc30 100644
> --- a/drivers/iio/adc/ti-ads131e08.c
> +++ b/drivers/iio/adc/ti-ads131e08.c
> @@ -827,7 +827,7 @@ static int ads131e08_probe(struct spi_device *spi)
> if (spi->irq) {
> ret = devm_request_irq(&spi->dev, spi->irq,
> ads131e08_interrupt,
> - IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> + IRQF_TRIGGER_FALLING | IRQF_NO_THREAD,
> spi->dev.driver->name, indio_dev);
> if (ret)
> return dev_err_probe(&spi->dev, ret,
> diff --git a/drivers/iio/chemical/ens160_core.c b/drivers/iio/chemical/ens160_core.c
> index 86bde4a91bf7e..bbc96c4c62838 100644
> --- a/drivers/iio/chemical/ens160_core.c
> +++ b/drivers/iio/chemical/ens160_core.c
> @@ -316,12 +316,9 @@ static int ens160_setup_trigger(struct iio_dev *indio_dev, int irq)
>
> indio_dev->trig = iio_trigger_get(trig);
>
> - ret = devm_request_threaded_irq(dev, irq,
> - iio_trigger_generic_data_rdy_poll,
> - NULL,
> - IRQF_ONESHOT,
> - indio_dev->name,
> - indio_dev->trig);
> + ret = devm_request_irq(dev, irq, iio_trigger_generic_data_rdy_poll,
> + IRQF_NO_THREAD, indio_dev->name,
> + indio_dev->trig);
> if (ret)
> return dev_err_probe(dev, ret, "failed to request irq\n");
>
> diff --git a/drivers/iio/gyro/adxrs290.c b/drivers/iio/gyro/adxrs290.c
> index 8fcb41f45baac..3efe385ebedc4 100644
> --- a/drivers/iio/gyro/adxrs290.c
> +++ b/drivers/iio/gyro/adxrs290.c
> @@ -597,7 +597,7 @@ static int adxrs290_probe_trigger(struct iio_dev *indio_dev)
>
> ret = devm_request_irq(&st->spi->dev, st->spi->irq,
> &iio_trigger_generic_data_rdy_poll,
> - IRQF_ONESHOT, "adxrs290_irq", st->dready_trig);
> + IRQF_NO_THREAD, "adxrs290_irq", st->dready_trig);
> if (ret < 0)
> return dev_err_probe(&st->spi->dev, ret,
> "request irq %d failed\n", st->spi->irq);
> diff --git a/drivers/iio/health/afe4403.c b/drivers/iio/health/afe4403.c
> index 0e5a512e3bb8f..d358f4d5e5da8 100644
> --- a/drivers/iio/health/afe4403.c
> +++ b/drivers/iio/health/afe4403.c
> @@ -540,11 +540,10 @@ static int afe4403_probe(struct spi_device *spi)
> return ret;
> }
>
> - ret = devm_request_threaded_irq(dev, afe->irq,
> - iio_trigger_generic_data_rdy_poll,
> - NULL, IRQF_ONESHOT,
> - AFE4403_DRIVER_NAME,
> - afe->trig);
> + ret = devm_request_irq(dev, afe->irq,
> + iio_trigger_generic_data_rdy_poll,
> + IRQF_NO_THREAD, AFE4403_DRIVER_NAME,
> + afe->trig);
> if (ret) {
> dev_err(dev, "Unable to request IRQ\n");
> return ret;
> diff --git a/drivers/iio/health/afe4404.c b/drivers/iio/health/afe4404.c
> index 768d794e574b9..032da52a96d0e 100644
> --- a/drivers/iio/health/afe4404.c
> +++ b/drivers/iio/health/afe4404.c
> @@ -547,11 +547,10 @@ static int afe4404_probe(struct i2c_client *client)
> return ret;
> }
>
> - ret = devm_request_threaded_irq(dev, afe->irq,
> - iio_trigger_generic_data_rdy_poll,
> - NULL, IRQF_ONESHOT,
> - AFE4404_DRIVER_NAME,
> - afe->trig);
> + ret = devm_request_irq(dev, afe->irq,
> + iio_trigger_generic_data_rdy_poll,
> + IRQF_NO_THREAD, AFE4404_DRIVER_NAME,
> + afe->trig);
> if (ret) {
> dev_err(dev, "Unable to request IRQ\n");
> return ret;
> diff --git a/drivers/iio/magnetometer/bmc150_magn.c b/drivers/iio/magnetometer/bmc150_magn.c
> index 6a73f6e2f1f06..a022e1805dff7 100644
> --- a/drivers/iio/magnetometer/bmc150_magn.c
> +++ b/drivers/iio/magnetometer/bmc150_magn.c
> @@ -906,12 +906,9 @@ int bmc150_magn_probe(struct device *dev, struct regmap *regmap,
> goto err_poweroff;
> }
>
> - ret = request_threaded_irq(irq,
> - iio_trigger_generic_data_rdy_poll,
> - NULL,
> - IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> - "bmc150_magn_event",
> - data->dready_trig);
> + ret = request_irq(irq, iio_trigger_generic_data_rdy_poll,
> + IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> + "bmc150_magn_event", data->dready_trig);
> if (ret < 0) {
> dev_err(dev, "request irq %d failed\n", irq);
> goto err_trigger_unregister;
> diff --git a/drivers/iio/pressure/dlhl60d.c b/drivers/iio/pressure/dlhl60d.c
> index 8bad7162fec64..e975b733ce0a1 100644
> --- a/drivers/iio/pressure/dlhl60d.c
> +++ b/drivers/iio/pressure/dlhl60d.c
> @@ -306,9 +306,9 @@ static int dlh_probe(struct i2c_client *client)
> indio_dev->num_channels = ARRAY_SIZE(dlh_channels);
>
> if (client->irq > 0) {
> - ret = devm_request_threaded_irq(&client->dev, client->irq,
> - dlh_interrupt, NULL,
> - IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> + ret = devm_request_irq(&client->dev, client->irq,
> + dlh_interrupt,
> + IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> st->info->name, indio_dev);
> if (ret) {
> dev_err(&client->dev, "failed to allocate threaded irq");
> diff --git a/drivers/iio/temperature/tmp006.c b/drivers/iio/temperature/tmp006.c
> index 10bd3f221929d..d8d8c8936d177 100644
> --- a/drivers/iio/temperature/tmp006.c
> +++ b/drivers/iio/temperature/tmp006.c
> @@ -356,12 +356,10 @@ static int tmp006_probe(struct i2c_client *client)
>
> indio_dev->trig = iio_trigger_get(data->drdy_trig);
>
> - ret = devm_request_threaded_irq(&client->dev, client->irq,
> - iio_trigger_generic_data_rdy_poll,
> - NULL,
> - IRQF_ONESHOT,
> - "tmp006_irq",
> - data->drdy_trig);
> + ret = devm_request_irq(&client->dev, client->irq,
> + iio_trigger_generic_data_rdy_poll,
> + IRQF_NO_THREAD, "tmp006_irq",
> + data->drdy_trig);
> if (ret < 0)
> return ret;
> }
On Fri, Jan 23, 2026 at 12:37:04PM +0100, Sebastian Andrzej Siewior wrote: > Passing IRQF_ONESHOT ensures that the interrupt source is masked until > the secondary (threaded) handler is done. If only a primary handler is > used then the flag makes no sense because the interrupt can not fire > (again) while its handler is running. > The flag also disallows force-threading of the primary handler and the > irq-core will warn about this. > > The intention here was probably not allowing forced-threading for > handlers such as iio_trigger_generic_data_rdy_poll() will intends to > invoke hard-interrupt handlers. > > Replace IRQF_ONESHOT with IRQF_NO_THREAD. > > Cc: Lars-Peter Clausen <lars@metafoo.de> > Cc: Michael Hennerich <Michael.Hennerich@analog.com> > Cc: Puranjay Mohan <puranjay@kernel.org> > Cc: Jonathan Cameron <jic23@kernel.org> > Cc: David Lechner <dlechner@baylibre.com> > Cc: "Nuno Sá" <nuno.sa@analog.com> > Cc: Andy Shevchenko <andy@kernel.org> > Cc: Marcelo Schmitt <marcelo.schmitt@analog.com> > Cc: Marcus Folkesson <marcus.folkesson@gmail.com> > Cc: Kent Gustavsson <kent@minoris.se> > Cc: Gustavo Silva <gustavograzs@gmail.com> > Cc: Nishant Malpani <nish.malpani25@gmail.com> > Cc: linux-iio@vger.kernel.org > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > --- [...] > drivers/iio/adc/mcp3911.c | 2 +- Reviewed-by: Marcus Folkesson <marcus.folkesson@gmail.com> Best regards, Marcus Folkesson
On Fri, Jan 23, 2026 at 12:37:04PM +0100, Sebastian Andrzej Siewior wrote:
> Passing IRQF_ONESHOT ensures that the interrupt source is masked until
> the secondary (threaded) handler is done. If only a primary handler is
> used then the flag makes no sense because the interrupt can not fire
> (again) while its handler is running.
> The flag also disallows force-threading of the primary handler and the
> irq-core will warn about this.
>
> The intention here was probably not allowing forced-threading for
> handlers such as iio_trigger_generic_data_rdy_poll() will intends to
> invoke hard-interrupt handlers.
>
> Replace IRQF_ONESHOT with IRQF_NO_THREAD.
Code wise LGTM,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
There is a few nit-picks regarding style below.
...
> Cc: Lars-Peter Clausen <lars@metafoo.de>
> Cc: Michael Hennerich <Michael.Hennerich@analog.com>
> Cc: Puranjay Mohan <puranjay@kernel.org>
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: Marcelo Schmitt <marcelo.schmitt@analog.com>
> Cc: Marcus Folkesson <marcus.folkesson@gmail.com>
> Cc: Kent Gustavsson <kent@minoris.se>
> Cc: Gustavo Silva <gustavograzs@gmail.com>
> Cc: Nishant Malpani <nish.malpani25@gmail.com>
> Cc: linux-iio@vger.kernel.org
Move these...
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
...to be here. This will drastically reduce the unneeded noise in the commit
message. The email will have (if using git format-patch and git send-email)
them.
...
> --- a/drivers/iio/accel/adxl355_core.c
> +++ b/drivers/iio/accel/adxl355_core.c
> @@ -770,7 +770,8 @@ static int adxl355_probe_trigger(struct iio_dev *indio_dev, int irq)
>
> ret = devm_request_irq(data->dev, irq,
> &iio_trigger_generic_data_rdy_poll,
> - IRQF_ONESHOT, "adxl355_irq", data->dready_trig);
> + IRQF_NO_THREAD,
> + "adxl355_irq", data->dready_trig);
Leave it on a single line. It's only 81 characters and it's fine to be like
this.
> if (ret)
> return dev_err_probe(data->dev, ret, "request irq %d failed\n",
> irq);
...
> +++ b/drivers/iio/accel/adxl372.c
> + ret = devm_request_irq(dev, st->irq,
> + iio_trigger_generic_data_rdy_poll,
> + IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> + indio_dev->name, st->dready_trig);
> if (ret < 0)
> return ret;
Interestingly that this driver ignores the flags from firmware... Seems to me
like a bug (not in your patch, obviously). Ditto for other drivers doing similar
things.
...
> --- a/drivers/iio/pressure/dlhl60d.c
> +++ b/drivers/iio/pressure/dlhl60d.c
> @@ -306,9 +306,9 @@ static int dlh_probe(struct i2c_client *client)
> indio_dev->num_channels = ARRAY_SIZE(dlh_channels);
>
> if (client->irq > 0) {
> - ret = devm_request_threaded_irq(&client->dev, client->irq,
> - dlh_interrupt, NULL,
> - IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> + ret = devm_request_irq(&client->dev, client->irq,
> + dlh_interrupt,
Joined to the previous line it gives exactly 80 characters, which is allowed.
> + IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> st->info->name, indio_dev);
Forgot to indent.
...
> + ret = devm_request_irq(&client->dev, client->irq,
> + iio_trigger_generic_data_rdy_poll,
> + IRQF_NO_THREAD, "tmp006_irq",
> + data->drdy_trig);
> if (ret < 0)
> return ret;
Jonathan et al., this seems to me like a duplication from one to another
driver. Can't we do like a helper for it, so we don't change it each time
the IRQ core or other things got changed?
--
With Best Regards,
Andy Shevchenko
On 2026-01-23 16:48:54 [+0200], Andy Shevchenko wrote:
> On Fri, Jan 23, 2026 at 12:37:04PM +0100, Sebastian Andrzej Siewior wrote:
> > Passing IRQF_ONESHOT ensures that the interrupt source is masked until
> > the secondary (threaded) handler is done. If only a primary handler is
> > used then the flag makes no sense because the interrupt can not fire
> > (again) while its handler is running.
> > The flag also disallows force-threading of the primary handler and the
> > irq-core will warn about this.
> >
> > The intention here was probably not allowing forced-threading for
> > handlers such as iio_trigger_generic_data_rdy_poll() will intends to
> > invoke hard-interrupt handlers.
> >
> > Replace IRQF_ONESHOT with IRQF_NO_THREAD.
>
> Code wise LGTM,
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> There is a few nit-picks regarding style below.
>
> ...
>
> > Cc: Lars-Peter Clausen <lars@metafoo.de>
> > Cc: Michael Hennerich <Michael.Hennerich@analog.com>
> > Cc: Puranjay Mohan <puranjay@kernel.org>
> > Cc: Jonathan Cameron <jic23@kernel.org>
> > Cc: David Lechner <dlechner@baylibre.com>
> > Cc: "Nuno Sá" <nuno.sa@analog.com>
> > Cc: Andy Shevchenko <andy@kernel.org>
> > Cc: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > Cc: Marcus Folkesson <marcus.folkesson@gmail.com>
> > Cc: Kent Gustavsson <kent@minoris.se>
> > Cc: Gustavo Silva <gustavograzs@gmail.com>
> > Cc: Nishant Malpani <nish.malpani25@gmail.com>
> > Cc: linux-iio@vger.kernel.org
>
> Move these...
>
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > ---
>
> ...to be here. This will drastically reduce the unneeded noise in the commit
> message. The email will have (if using git format-patch and git send-email)
> them.
Yeah but if I have to send v2 then they are gone, aren't they? So I have
to move them for each submission. Or is there something I am not aware
of?
> ...
>
> > --- a/drivers/iio/accel/adxl355_core.c
> > +++ b/drivers/iio/accel/adxl355_core.c
> > @@ -770,7 +770,8 @@ static int adxl355_probe_trigger(struct iio_dev *indio_dev, int irq)
> >
> > ret = devm_request_irq(data->dev, irq,
> > &iio_trigger_generic_data_rdy_poll,
> > - IRQF_ONESHOT, "adxl355_irq", data->dready_trig);
> > + IRQF_NO_THREAD,
> > + "adxl355_irq", data->dready_trig);
>
> Leave it on a single line. It's only 81 characters and it's fine to be like
> this.
>
> > if (ret)
> > return dev_err_probe(data->dev, ret, "request irq %d failed\n",
> > irq);
>
> ...
>
> > +++ b/drivers/iio/accel/adxl372.c
>
> > + ret = devm_request_irq(dev, st->irq,
> > + iio_trigger_generic_data_rdy_poll,
> > + IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> > + indio_dev->name, st->dready_trig);
> > if (ret < 0)
> > return ret;
>
> Interestingly that this driver ignores the flags from firmware... Seems to me
> like a bug (not in your patch, obviously). Ditto for other drivers doing similar
> things.
If the irq-chip is level or unknown mode on boot up/ default and the
device can only operate as an edge-rising then I don't see why this
should be a bug.
> ...
>
> > --- a/drivers/iio/pressure/dlhl60d.c
> > +++ b/drivers/iio/pressure/dlhl60d.c
> > @@ -306,9 +306,9 @@ static int dlh_probe(struct i2c_client *client)
> > indio_dev->num_channels = ARRAY_SIZE(dlh_channels);
> >
> > if (client->irq > 0) {
> > - ret = devm_request_threaded_irq(&client->dev, client->irq,
> > - dlh_interrupt, NULL,
> > - IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> > + ret = devm_request_irq(&client->dev, client->irq,
> > + dlh_interrupt,
>
> Joined to the previous line it gives exactly 80 characters, which is allowed.
>
> > + IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> > st->info->name, indio_dev);
>
> Forgot to indent.
Okay, let me fix this up.
>
> ...
>
> > + ret = devm_request_irq(&client->dev, client->irq,
> > + iio_trigger_generic_data_rdy_poll,
> > + IRQF_NO_THREAD, "tmp006_irq",
> > + data->drdy_trig);
> > if (ret < 0)
> > return ret;
>
> Jonathan et al., this seems to me like a duplication from one to another
> driver. Can't we do like a helper for it, so we don't change it each time
> the IRQ core or other things got changed?
>
Sebastian
On Mon, Jan 26, 2026 at 09:15:10AM +0100, Sebastian Andrzej Siewior wrote: > On 2026-01-23 16:48:54 [+0200], Andy Shevchenko wrote: > > On Fri, Jan 23, 2026 at 12:37:04PM +0100, Sebastian Andrzej Siewior wrote: ... > > > Cc: Lars-Peter Clausen <lars@metafoo.de> > > > Cc: Michael Hennerich <Michael.Hennerich@analog.com> > > > Cc: Puranjay Mohan <puranjay@kernel.org> > > > Cc: Jonathan Cameron <jic23@kernel.org> > > > Cc: David Lechner <dlechner@baylibre.com> > > > Cc: "Nuno Sá" <nuno.sa@analog.com> > > > Cc: Andy Shevchenko <andy@kernel.org> > > > Cc: Marcelo Schmitt <marcelo.schmitt@analog.com> > > > Cc: Marcus Folkesson <marcus.folkesson@gmail.com> > > > Cc: Kent Gustavsson <kent@minoris.se> > > > Cc: Gustavo Silva <gustavograzs@gmail.com> > > > Cc: Nishant Malpani <nish.malpani25@gmail.com> > > > Cc: linux-iio@vger.kernel.org > > > > Move these... > > > > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > > > --- > > > > ...to be here. This will drastically reduce the unneeded noise in the commit > > message. The email will have (if using git format-patch and git send-email) > > them. > > Yeah but if I have to send v2 then they are gone, aren't they? I didn't follow. How? What tools do you use? > So I have to move them for each submission. Or is there something I am not > aware of? Make them in the tail of commit messages locally with a delimiter, they will always be present as long as they are in your tree. I dunno if `b4` manages the Cc lists separately. At least I see no-one using `b4` *and* putting the Cc noise into the commit messages, so I assume it behaves nicely. ... > > > + ret = devm_request_irq(dev, st->irq, > > > + iio_trigger_generic_data_rdy_poll, > > > + IRQF_TRIGGER_RISING | IRQF_NO_THREAD, > > > + indio_dev->name, st->dready_trig); > > > if (ret < 0) > > > return ret; > > > > Interestingly that this driver ignores the flags from firmware... Seems to me > > like a bug (not in your patch, obviously). Ditto for other drivers doing similar > > things. > > If the irq-chip is level or unknown mode on boot up/ default and the > device can only operate as an edge-rising then I don't see why this > should be a bug. But if FW says use "level", wouldn't this setting override it? -- With Best Regards, Andy Shevchenko
On 2026-01-26 11:51:13 [+0200], Andy Shevchenko wrote: > > > > Cc: Lars-Peter Clausen <lars@metafoo.de> > > > > Cc: Michael Hennerich <Michael.Hennerich@analog.com> > > > > Cc: Puranjay Mohan <puranjay@kernel.org> > > > > Cc: Jonathan Cameron <jic23@kernel.org> > > > > Cc: David Lechner <dlechner@baylibre.com> > > > > Cc: "Nuno Sá" <nuno.sa@analog.com> > > > > Cc: Andy Shevchenko <andy@kernel.org> > > > > Cc: Marcelo Schmitt <marcelo.schmitt@analog.com> > > > > Cc: Marcus Folkesson <marcus.folkesson@gmail.com> > > > > Cc: Kent Gustavsson <kent@minoris.se> > > > > Cc: Gustavo Silva <gustavograzs@gmail.com> > > > > Cc: Nishant Malpani <nish.malpani25@gmail.com> > > > > Cc: linux-iio@vger.kernel.org > > > … > I didn't follow. How? What tools do you use? b4/ git. > > So I have to move them for each submission. Or is there something I am not > > aware of? > > Make them in the tail of commit messages locally with a delimiter, they will > always be present as long as they are in your tree. > > I dunno if `b4` manages the Cc lists separately. At least I see no-one using > `b4` *and* putting the Cc noise into the commit messages, so I assume it > behaves nicely. I point is if I move them for one submission, I lose it on the next if I update patches in tree and re-export them. > > > > + ret = devm_request_irq(dev, st->irq, > > > > + iio_trigger_generic_data_rdy_poll, > > > > + IRQF_TRIGGER_RISING | IRQF_NO_THREAD, > > > > + indio_dev->name, st->dready_trig); > > > > if (ret < 0) > > > > return ret; > > > > > > Interestingly that this driver ignores the flags from firmware... Seems to me > > > like a bug (not in your patch, obviously). Ditto for other drivers doing similar > > > things. > > > > If the irq-chip is level or unknown mode on boot up/ default and the > > device can only operate as an edge-rising then I don't see why this > > should be a bug. > > But if FW says use "level", wouldn't this setting override it? Yes, it will. It was common to use it pre-device-tree time where this information was not configured automatically before ->probe. Now it might be missing/wrong in the dt for some of the old devices. It might be a left-over which continued to grow and spread. Sebastian
On Mon, Jan 26, 2026 at 11:10:34AM +0100, Sebastian Andrzej Siewior wrote: > On 2026-01-26 11:51:13 [+0200], Andy Shevchenko wrote: > > > > > Cc: Lars-Peter Clausen <lars@metafoo.de> > > > > > Cc: Michael Hennerich <Michael.Hennerich@analog.com> > > > > > Cc: Puranjay Mohan <puranjay@kernel.org> > > > > > Cc: Jonathan Cameron <jic23@kernel.org> > > > > > Cc: David Lechner <dlechner@baylibre.com> > > > > > Cc: "Nuno Sá" <nuno.sa@analog.com> > > > > > Cc: Andy Shevchenko <andy@kernel.org> > > > > > Cc: Marcelo Schmitt <marcelo.schmitt@analog.com> > > > > > Cc: Marcus Folkesson <marcus.folkesson@gmail.com> > > > > > Cc: Kent Gustavsson <kent@minoris.se> > > > > > Cc: Gustavo Silva <gustavograzs@gmail.com> > > > > > Cc: Nishant Malpani <nish.malpani25@gmail.com> > > > > > Cc: linux-iio@vger.kernel.org > > > > > … > > I didn't follow. How? What tools do you use? > > b4/ git. > > > So I have to move them for each submission. Or is there something I am not > > > aware of? > > > > Make them in the tail of commit messages locally with a delimiter, they will > > always be present as long as they are in your tree. > > > > I dunno if `b4` manages the Cc lists separately. At least I see no-one using > > `b4` *and* putting the Cc noise into the commit messages, so I assume it > > behaves nicely. > > I point is if I move them for one submission, It will be in your Git tree as a part of the commit message. What I mean is that your commit message will be like $PREFIX: $SUMMARY ...blank line... $COMMIT_MESSAGE ...blank line... $TAG Signed-off-by: ... --- Cc: person 1 Cc: person 2 Just don't reimport them via `git am`. > I lose it on the next if I update patches in tree and re-export them. I don't understand this, sorry. Can you provide a step-by-step example? Do you mean that you are taking previous version from the list and reapplying it via `git am`? But shouldn't `b4` take care of that as long as it knows the Change-ID and it matches? ... Hmm... The https://b4.docs.kernel.org/en/latest/contributor/prep.html doesn't clearly tell me if there is a carry-on procedure for the Cc list between versions. ... > > > > > + ret = devm_request_irq(dev, st->irq, > > > > > + iio_trigger_generic_data_rdy_poll, > > > > > + IRQF_TRIGGER_RISING | IRQF_NO_THREAD, > > > > > + indio_dev->name, st->dready_trig); > > > > > if (ret < 0) > > > > > return ret; > > > > > > > > Interestingly that this driver ignores the flags from firmware... Seems to me > > > > like a bug (not in your patch, obviously). Ditto for other drivers doing similar > > > > things. > > > > > > If the irq-chip is level or unknown mode on boot up/ default and the > > > device can only operate as an edge-rising then I don't see why this > > > should be a bug. > > > > But if FW says use "level", wouldn't this setting override it? > > Yes, it will. It was common to use it pre-device-tree time where this > information was not configured automatically before ->probe. Now it > might be missing/wrong in the dt for some of the old devices. > It might be a left-over which continued to grow and spread. It may be considered as a bug, especially in the cases when the driver works only on DT/ACPI platforms. -- With Best Regards, Andy Shevchenko
On 2026-01-26 13:01:02 [+0200], Andy Shevchenko wrote: > --- > Cc: person 1 > Cc: person 2 > > Just don't reimport them via `git am`. > > > I lose it on the next if I update patches in tree and re-export them. > > I don't understand this, sorry. Can you provide a step-by-step example? > Do you mean that you are taking previous version from the list and reapplying > it via `git am`? But shouldn't `b4` take care of that as long as it knows the > Change-ID and it matches? So doing this and switching to b4 trailers to grab the tags actually help. Then I have been playing with prep. So thank you. Then I stumbled upon --auto-to-cc which picked up all addresses and added it to the cover letter which was fine. But then `send' used those for every patch in the series which I did not want. So for that part I probably stick with git-send-mail since this not in everyone's workflow (sending a series across multiple subsystems and avoiding flooding everyone). Anyway. This seems to have turned out nice. Sebastian
On Wed, Jan 28, 2026 at 11:07:36AM +0100, Sebastian Andrzej Siewior wrote: > On 2026-01-26 13:01:02 [+0200], Andy Shevchenko wrote: > > --- > > Cc: person 1 > > Cc: person 2 > > > > Just don't reimport them via `git am`. > > > > > I lose it on the next if I update patches in tree and re-export them. > > > > I don't understand this, sorry. Can you provide a step-by-step example? > > Do you mean that you are taking previous version from the list and reapplying > > it via `git am`? But shouldn't `b4` take care of that as long as it knows the > > Change-ID and it matches? > > So doing this and switching to b4 trailers to grab the tags actually > help. Then I have been playing with prep. So thank you. You're welcome! > Then I stumbled upon --auto-to-cc which picked up all addresses and > added it to the cover letter which was fine. But then `send' used those > for every patch in the series which I did not want. So for that part I > probably stick with git-send-mail since this not in everyone's workflow > (sending a series across multiple subsystems and avoiding flooding > everyone). I'm not an (advanced) user of `b4` yet. I have my own script to send based on some heuristics [1]. > Anyway. This seems to have turned out nice. Good! [1]: https://github.com/andy-shev/home-bin-tools/blob/master/ge2maintainer.sh -- With Best Regards, Andy Shevchenko
On Mon, Jan 26, 2026 at 01:01:02PM +0200, Andy Shevchenko wrote: > > I lose it on the next if I update patches in tree and re-export them. > > I don't understand this, sorry. Can you provide a step-by-step example? > Do you mean that you are taking previous version from the list and reapplying > it via `git am`? But shouldn't `b4` take care of that as long as it knows the > Change-ID and it matches? That's not the intended workflow -- the series is kept as a branch in your local tree and any updates happen to that branch, so any entries in a commit falling under "---" will persist across revisions. > Hmm... The https://b4.docs.kernel.org/en/latest/contributor/prep.html > doesn't clearly tell me if there is a carry-on procedure for the Cc > list between versions. There isn't any special procedure. ¯\_(ツ)_/¯ -K
On Mon, 2026-01-26 at 09:29 -0500, Konstantin Ryabitsev wrote: > On Mon, Jan 26, 2026 at 01:01:02PM +0200, Andy Shevchenko wrote: > > > I lose it on the next if I update patches in tree and re-export them. > > > > I don't understand this, sorry. Can you provide a step-by-step example? > > Do you mean that you are taking previous version from the list and reapplying > > it via `git am`? But shouldn't `b4` take care of that as long as it knows the > > Change-ID and it matches? > > That's not the intended workflow -- the series is kept as a branch in your > local tree and any updates happen to that branch, so any entries in a commit > falling under "---" will persist across revisions. > Hi Konstantin, Since I have you here, I might ask about something that I'm not sure how to handle. Might be dumb but here it goes. One problem is when I send v1 based on a branch and when I'm starting to work on v2 that branch was force-updated and I want to base my v2 on it. Is there any good way to handle this? What I currently do is more or less: git cat-file -p $COVER_SHA git reset --hard origin/branch git commit --allow-empty (and past all the cover with b4 metadata) // apply my series patches. Thx! - Nuno Sá >
On Wed, Jan 28, 2026, at 05:45, Nuno Sá wrote: > Since I have you here, I might ask about something that I'm not sure > how to handle. Might be dumb but here it goes. One problem is when I > send v1 based on a branch and when I'm starting to work on v2 that > branch was force-updated and I want to base my v2 on it. Is there any > good way to handle this? You should be able to just rebase the b4 branch. git switch b4/your-branch git rebase tracking-branch You can do this at any point, not necessarily between revisions. Since we have the tracking empty commit, we'll always know the base-commit automatically. -K
On Mon, Jan 26, 2026 at 09:29:45AM -0500, Konstantin Ryabitsev wrote: > On Mon, Jan 26, 2026 at 01:01:02PM +0200, Andy Shevchenko wrote: > > > I lose it on the next if I update patches in tree and re-export them. > > > > I don't understand this, sorry. Can you provide a step-by-step example? > > Do you mean that you are taking previous version from the list and reapplying > > it via `git am`? But shouldn't `b4` take care of that as long as it knows the > > Change-ID and it matches? > > That's not the intended workflow -- the series is kept as a branch in your > local tree and any updates happen to that branch, so any entries in a commit > falling under "---" will persist across revisions. Right. I found `b4 trailers` do a really good job to inject collected trailers into the Git repo without need of any `git reset; b4 am; git am` dances. > > Hmm... The https://b4.docs.kernel.org/en/latest/contributor/prep.html > > doesn't clearly tell me if there is a carry-on procedure for the Cc > > list between versions. > > There isn't any special procedure. ¯\_(ツ)_/¯ What I have i mind is rather the scenario when I see already sent (by somebody else) patch in the mailing list and I want develop a followup with the same To/Cc list. So I want `b4 ... --use/restore-to-cc-from-the-mailing-list / lore` type of functionality. -- With Best Regards, Andy Shevchenko
On Mon, Jan 26, 2026 at 04:57:24PM +0200, Andy Shevchenko wrote: > What I have i mind is rather the scenario when I see already sent (by somebody > else) patch in the mailing list and I want develop a followup with the same > To/Cc list. So I want `b4 ... --use/restore-to-cc-from-the-mailing-list / lore` > type of functionality. To understand it better -- you want to send a new revision to a patch sent by someone else? If so, you should be able to "b4 prep --from-thread <msgid>", but it's actually a good question if that will do the right thing with content under "---" or not, as I'm not sure this part was ever properly tested. -K
On Mon, Jan 26, 2026 at 10:09:25AM -0500, Konstantin Ryabitsev wrote: > On Mon, Jan 26, 2026 at 04:57:24PM +0200, Andy Shevchenko wrote: > > What I have i mind is rather the scenario when I see already sent (by somebody > > else) patch in the mailing list and I want develop a followup with the same > > To/Cc list. So I want `b4 ... --use/restore-to-cc-from-the-mailing-list / lore` > > type of functionality. > To understand it better -- you want to send a new revision to a patch sent by > someone else? Like this or when I want to send another patch on top of what has been sent to the same people. > If so, you should be able to "b4 prep --from-thread <msgid>", > but it's actually a good question if that will do the right thing with content > under "---" or not, as I'm not sure this part was ever properly tested. But that's not needed, as it's assumed to be in the *email* Cc and To already, so that's it then. I will try the suggested command, thanks! More complex case is to preserve that locally, but it might be not needed after all. Thanks for the suggestions and nice tool! -- With Best Regards, Andy Shevchenko
> > +++ b/drivers/iio/accel/adxl372.c
>
> > + ret = devm_request_irq(dev, st->irq,
> > + iio_trigger_generic_data_rdy_poll,
> > + IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> > + indio_dev->name, st->dready_trig);
> > if (ret < 0)
> > return ret;
>
> Interestingly that this driver ignores the flags from firmware... Seems to me
> like a bug (not in your patch, obviously). Ditto for other drivers doing similar
> things.
>
It's indeed a bug but one of those historic ones we can't fix without
high risk of regressions :(
> ...
>
> > --- a/drivers/iio/pressure/dlhl60d.c
> > +++ b/drivers/iio/pressure/dlhl60d.c
> > @@ -306,9 +306,9 @@ static int dlh_probe(struct i2c_client *client)
> > indio_dev->num_channels = ARRAY_SIZE(dlh_channels);
> >
> > if (client->irq > 0) {
> > - ret = devm_request_threaded_irq(&client->dev, client->irq,
> > - dlh_interrupt, NULL,
> > - IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> > + ret = devm_request_irq(&client->dev, client->irq,
> > + dlh_interrupt,
>
> Joined to the previous line it gives exactly 80 characters, which is allowed.
>
> > + IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> > st->info->name, indio_dev);
>
> Forgot to indent.
>
> ...
>
> > + ret = devm_request_irq(&client->dev, client->irq,
> > + iio_trigger_generic_data_rdy_poll,
> > + IRQF_NO_THREAD, "tmp006_irq",
> > + data->drdy_trig);
> > if (ret < 0)
> > return ret;
>
> Jonathan et al., this seems to me like a duplication from one to another
> driver. Can't we do like a helper for it, so we don't change it each time
> the IRQ core or other things got changed?
I'm not sure what the helper would include that would shorten things much:
could hide two params, but need a longer name and that's going to be
hard to find. So maybe...
J
>
On 1/23/26 10:47 AM, Jonathan Cameron wrote: > >>> +++ b/drivers/iio/accel/adxl372.c >> >>> + ret = devm_request_irq(dev, st->irq, >>> + iio_trigger_generic_data_rdy_poll, >>> + IRQF_TRIGGER_RISING | IRQF_NO_THREAD, >>> + indio_dev->name, st->dready_trig); >>> if (ret < 0) >>> return ret; >> >> Interestingly that this driver ignores the flags from firmware... Seems to me >> like a bug (not in your patch, obviously). Ditto for other drivers doing similar >> things. >> > > It's indeed a bug but one of those historic ones we can't fix without > high risk of regressions :( > > Sounds like we should add a "don't copy this because ..." comment while we are touching this.
© 2016 - 2026 Red Hat, Inc.