On Thu, 24 Mar 2011, Thomas Gleixner wrote: > On Thu, 24 Mar 2011, Maciej W. Rozycki wrote: > > > On Thu, 24 Mar 2011, Ralf Baechle wrote: > > > > > Thanks, queued for 2.6.39. > > > > Ralf, thanks for cc-ing me. > > > > NACK, where's the logic to ack IOASIC DMA IRQs gone? The SIR has to be > > written as in clear_ioasic_irq() for the respective DMA transfer to resume > > and the interrupt in question be able to retrigger in the future. > > Errm. > > #define ack_ioasic_dma_irq ack_ioasic_irq > > .name = "IO-ASIC-DMA", > .ack = ack_ioasic_dma_irq > > So the .ack pointer is filled with ack_ioasic_irq, right ? The ack used to be made in clear_ioasic_irq(), that was called from end_ioasic_dma_irq(), that was used as the .end handler. This semantics has to be preserved or hardware won't work anymore as expected. This is a regression. > So I did: > > -#define ack_ioasic_dma_irq ack_ioasic_irq > > + .irq_ack = ack_ioasic_irq, > > Pretty identical as far as I can tell. The define is rather pointless, > isn't it ? Yes, but it's not the .ack handler I'm concerned about, but the hardware ack that has to be made once higher-level processing has finished. > > The rest is probably OK, but why has the inline hint been removed? > > These functions are simple, worth a couple of assembly instructions at > > most and used throughout these files, so it's good to ask GCC to inline > > them if worthwhile even if -fno-unit-at-a-time has been requested for > > whatever reason. > > The only use of these functions is in the chip pointers, so the inline > is pointless. But I really dont care. mask_ioasic_irq() is called from ack_ioasic_irq() for one. Maciej
