The IRQ enable/disable in the PLIC - is a read/modify/write operation
(Either set a bit or clear a bit).
Why is this not protected by an CPU irq disable/restore?
Otherwise if an IRQ occurs in the middle of the read/modify/write operation there will be a bug in the user application - ie: The irq was not enabled or disabled like it should be Due to a race condtion.
Its ok to NOT - disable/enable/restore the IRQ - but you need to document the fact that the CALLER is responsible to disable the interrupts when you are enabling or disabling the interrupts in the PLIC .. (say that 3 times fast and you might think that is funny, hence I think this code should handle that for you)
It would be nice if the PLIC interface (and the APB bus supported ATOMIC read/writes from the RISCV - but - the ARM busses do not support atomic operations thus the ATOMIC instructions are useless on this CPU.
The IRQ enable/disable in the PLIC - is a read/modify/write operation (Either set a bit or clear a bit).
Why is this not protected by an CPU irq disable/restore? Otherwise if an IRQ occurs in the middle of the read/modify/write operation there will be a bug in the user application - ie: The irq was not enabled or disabled like it should be Due to a race condtion.
Its ok to NOT - disable/enable/restore the IRQ - but you need to document the fact that the CALLER is responsible to disable the interrupts when you are enabling or disabling the interrupts in the PLIC .. (say that 3 times fast and you might think that is funny, hence I think this code should handle that for you)
It would be nice if the PLIC interface (and the APB bus supported ATOMIC read/writes from the RISCV - but - the ARM busses do not support atomic operations thus the ATOMIC instructions are useless on this CPU.