[okl4-developer] OKL4 v2.1: Interrupt management offered to OK-Linux

[Frank Kaiser]

Hello

 

When a Linux driver wants to use a hardware interrupt, it seems to be
expected to use some functions provided by file
arch/l4/kernel/sys_iguana.c. When adapting a touch screen driver to our
AT91SAM9263 board we found that the driver lost the interrupt completely
after a disable/enable cycle. This phenomenon seems to be related to a
dubious implementation in the mentioned file. It provides 5 functions:

*       iguana_startup_irq(unsigned int irq)
If irq < 32 (why that?), hardware_register_interrupt() is called which
sends and IPC to the Iguana Server which invokes L4_RegisterInterrupt().
The rationale of this indirection seems to be to overcome the missing
security control for the caller of the function. Independently of of the
irq number the function iguana_enable_irq() is called.

*       iguana_ack_irq(unsigned int irq)
This function is empty, so why is it there?

*       iguana_end_irq(unsigned int irq)
This function calls iguana_enable_irq(), if the irq state is not
disabled or in progress. What shall be ended here?

*       iguana_disable_irq(unsigned int irq)
If irq < 32 (why that?), L4_UnregisterInterrupt() is called, otherwise a
bit in the variable irq_mask is masked. The bit is determined by the
operation 1UL << irq which leads to nothing since irq_mask is of type
unsigned long int which is of size 32 bit, while the shift operation
leads to a value bigger than that. Apparently the direkt call of
L4_UnregisterInterrupt() works, although it should be rejected if the
security control for the caller is not given.

*       iguana_enable_irq(unsigned int irq)
If irq < 32 (why that?), L4_AcknowledgeInterruptOnBehalf() is called,
otherwise the already mentioned meaningless operation on the variable
irq_mask is applied. I do not see how this enables an interrupt at L4
kernel level which has been unregistered (= disabled) before.

The observed behaviour is that the call of iguana_startup_irq()
activates an interrupt at L4 kernel level, the call of
iguana_disable_irq() deactivates it and the call of iguana_enable_irq()
never reactivates it again. Adding to this the many FIXME comments in
the file, I have some doubt that this file is fully functional. We are
not reluctant to repair this mess, but before doing so we have to
understand what this assembly of 5 interrupt management functions is
expected to do, and what, among others, is the purpose of the check
against this magic value 32. Can anybody tell?

 

Regards

Frank

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20080923/8ffe3386/attachment.htm