Adding IRQ_FLAG_NTF_X_HOOK to stop IRQ processing

[AlvyneZ]

Adding IRQ_FLAG_NTF_X_HOOK to stop IRQ processing from within an irq's notify hook.

IRQ_FLAG_NTF_X_HOOK shares the same bit with IRQ_FLAG_INIT, since at this point its functionality has already come to an end. And the NTF_X_HOOK flag is cleared immediately after its setting is detected.

[gatk555]

A neat plan to re-use the INIT flag!

I do not like the "continue", and attempt to reverse any effect of earlier calls. My guess is that it is only the FILTERED flag that prevents that causing an infinite loop in the ioport code. Also, I think the only proper use of this is in the core peripheral handlers. If _avr_alloc_irq_hook() was changed to keep the hook list in historic order of requests, they would always be called first, and there is nothing to undo.

Can the flag be renamed to something simpler, perhaps STOP?

Is the change in attiny85_i2cslave.c related to the rest? If not please say so in the commit comment.

Thanks, G.

[AlvyneZ]

You're right about the order of _avr_alloc_irq_hook() needing to be changed to keep the hook list in historic order of requests. At first glance because of the while loop traversing the list, it seemed to me as a non-issue. But I have edited it to ensure that subsequent hooks and chained irqs are added to the tail of the list.

Also, tracing back when the avr_ioport_irq_notify() hook is registered, I have seen that it follows the order of the registered ports. The order of ports (just like hooks) is also an inversion of the registering order (avr_register_io). This order made the usi hooks to be registered before the ioport hooks, both registering being done in the reset phase. I have edited it to ensure subsequent ports are added to the tail of the registered ports list.

I am testing the changes I am making using board_usi_i2cslave...
The change in attiny85_i2cslave.c is related. When the USIDR was being cleared after outputting data onto the line, setting 0x00 would end up having the MSB (0), pushed onto the line. Without the stopping of the processing on AVR_IOPORT_OUTPUT, the device would always detect an ACK. So I had to set it to 0x80, with MSB (1), leaving the receiver a chance to pull the line low.
But now with the stopping of hooks processing, the 0x80 workaround is no longer needed.. So I was getting rid of it.

[gatk555]

The code looks good, but please put something in the commit comment or code to say that the IO and IRQ chains need to be ordered by history so IOPORT has full control of the pin IRQs. And mention that the core changes allow a hack to be removed from the i2c example. thanks, G.

[gatk555]

Making my final check before merging, a test, test_atmega2560_pin_change.tst, was failing. It happens because the test was coded to work around the old behaviour, and that is now fixed. But when you did the CI check run, everything passed. Do you know anything that would explain that? Also, what result do you get running the tests?

Thanks, G.

[gatk555]

There is a simple fix for the test failure if another bug is fixed first. Merged, but for some reason not cloed automatically.