Wolfgang Grandegger wrote: > Jan Kiszka wrote: >> Hi Wolfgang, >> >> in the process of preparing to merge rtdm_irq_enable into >> rtdm_irq_request I would like to check if the attached patch is ok, thus >> we could finally drop rtdm_irq_enable once the API is refactored. Please >> check carefully when the first IRQs may happen and what the handler >> expects to be initialised! SJA1000 /should/ be ok as it works with > >> shared IRQs, but MSCAN does not (why, BTW?) and /may/ stumble. > > OK. Why should I use shared interrupts if there is no need? Most > embedded PowerPC systems have a dedicated interrupt source. Of course, /me forgot once again that not all the world is designed like crappy x86. :) At this chance I looked over the irq_flag mechanism of the CAN stack and found a minor cleanup: this #ifdef [1] is not required. If there is no sharing support, the subscriber will simply be redirected to the non-shared handler. @Dmitry: What happens under CONFIG_XENO_OPT_SHIRQ_LEVEL && !CONFIG_XENO_OPT_SHIRQ_EDGE when someone comes along with XN_ISR_SHARED|XN_ISR_EDGE? Looks like the level-triggered shared handler gets installed. Should we catch this? At Kconfig or at nucleus level? Jan [1]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/sja1000/rtcan_peak_pci.c?v=SVN-trunk#L233