Re: [PATCH v2] iio: pressure: rohm-bm1390: notify trigger on all error paths

[Matti Vaittinen <mazziesaccount@gmail.com>]

On 03/06/2026 20:26, Jonathan Cameron wrote:
> On Fri, 29 May 2026 11:21:40 +0300
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> 
>> On 22/05/2026 15:38, Matti Vaittinen wrote:
>>> On 20/05/2026 14:08, Jonathan Cameron wrote:
>>>> On Tue, 19 May 2026 08:48:13 +0300
>>>> Matti Vaittinen <mazziesaccount@gmail.com> wrote:

//snip

>> [  251.368583] irq 64: nobody cared (try booting with the "irqpoll" option)
>> [  251.375463] CPU: 0 UID: 0 PID: 835 Comm: irq/63-2-005d-b Tainted: G
>>           O        7.1.0-rc1-00002-g3b459deb7222-dirty #249 VOLUNTARY
>> [  251.375501] Tainted: [O]=OOT_MODULE
>> [  251.375511] Hardware name: Generic AM33XX (Flattened Device Tree)
>> [  251.375525] Call trace:
>> [  251.375545]  unwind_backtrace from show_stack+0x10/0x14
>> [  251.375607]  show_stack from dump_stack_lvl+0x50/0x64
>> [  251.375646]  dump_stack_lvl from __report_bad_irq+0x30/0xbc
>> [  251.375680]  __report_bad_irq from note_interrupt+0x2b4/0x32c
>> [  251.375722]  note_interrupt from handle_nested_irq+0x13c/0x14c
>> [  251.375758]  handle_nested_irq from iio_trigger_poll_nested+0x4c/0x68
>> [industrialio]
>> [  251.375917]  iio_trigger_poll_nested [industrialio] from
>> bm1390_irq_thread_handler+0x54/0x7c [rohm_bm1390]
>> [  251.375994]  bm1390_irq_thread_handler [rohm_bm1390] from
>> irq_thread_fn+0x1c/0x78
>> [  251.376028]  irq_thread_fn from irq_thread+0x18c/0x324
>> [  251.376057]  irq_thread from kthread+0xf8/0x130
>> [  251.376091]  kthread from ret_from_fork+0x14/0x20
>> [  251.376114] Exception stack(0xe0355fb0 to 0xe0355ff8)
>> [  251.376136] 5fa0:                                     00000000
>> 00000000 00000000 00000000
>> [  251.376156] 5fc0: 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000 00000000
>> [  251.376175] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>> [  251.376189] handlers:
>> [  251.498714] [<2ec7a5d9>] iio_pollfunc_store_time [industrialio]
>> threaded [<7f4268a2>] bm1390_trigger_handler [rohm_bm1390]
>> [  251.509974] Disabling IRQ #64
>>
>> Message from syslogd@arm at Jan  1 01:17:33 ...
>>    kernel:[  251.509974] Disabling IRQ #64
>> [  252.822500] sched: RT throttling activated
>>
>>
>> Things I very hastly picked up:
>>
>> 1. The throttling mechanism works even though the handling is invoked
>> via iio_trigger_poll_nested(), Probably because this propagates the call
>> to the handle_nested_irq() - which does bookkeeping.
> 
> Great.  At least it squashes something.

Yes. We get the nice trace in logs, clearly pointing to the guilty one.

>>
>> 2. For some reason (which I didn't have time to check yet), the
>> beaglebone black which I used to run this, was not completely blocked by
>> the IRQ. We can see the "Hack, return IRQ_NONE (xxx th)" -prints
>> emerging just fine.
> 
> After the Disabling IRQ #64 message?

No. The prints were spilled out regularly, even before the IRQ got 
disabled. So, CPU was not completely consumed by the IRQs. I am not sure 
if the IRQ thread gets preempted (what is the default scheduling policy 
for IRQ threads?), or if we have some other safety mechanism letting 
other stuff be executed. In any case, the system stayed somewhat responsive.

***

I did also try a hack which returned the IRQ_NONE, but did not call the 
iio_trigger_notify_done(). Result was as expected - the IRQ stayed 
asserted as the bm1390_trigger_handler() was not invoked repeatedly. 
Furthermore, the very helpful log entry was not spilled.

I suppose that now, because the system stayed somewhat responsive (even 
when the IRQ stayed active in the background), it wasn't exactly hard to 
check the IRQ counters and spot the culprit from there.

As a bottom line, I would love to see this fix getting merged, even 
though it doesn't seem as crucial I thought it was. Checking the log is 
still first thing one does when spotting a problem - and the entry there 
was to the point. Not all systems capture IRQ counters when an error 
occurs - while many still capture the kernel logs :)

Yours,
	-- Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~