Ok. Thanks for information. I guess I need to remove this code from my driver. This code is part of cx(4) and ctau(4) drivers. These cards are legacy ISA cards, IRQ line could be set any (from a definite set). The only reason why we probe for IRQ is to write to the user messages that IRQ is not functional - most probable it is assigned fot PCI/PNP. After we add this code calls to our tech support with question why device is not working (due to this reason) decreased twice. rik Bruce Evans wrote: >On Thu, 17 Jun 2004, Roman Kurakin wrote: > > >>Bruce Evans wrote: >> >> >>> [using isa_irq_pending()] >>> >>> >>> >>So spin lock should help me in some cases but there is other cases were >>this wouldn't help or I miss >>smth? >> >> > >Right. isa_irq_pending() only works right for isa devices at boot time >(not for probing later). > > > >>In this case if some driver will acquire interrupt while probing >>and after this it will release it >>(for example it will decide that this is wrong intr and will try other), >>and after we will try to load >>sio driver we may fail to load it case we would unable to check this >>intr line. >> >> > >sio only uses this mechanism to print a helpful (?) message about which >irqs it found. It gives priority to the irq resource. > >There's really nothing better than actually setting up the irq and >seeing if one arrives. sio doesn't do this mainly because when it was >written its probe was run before interrupts are fully unmasked (they >were blocked by splhigh() until the end of isa_configure()). npx used >to have the same problem, but I changed it to use bus_setup_intr() >normally. This caused new problems which were only fixed recently in >npx and are unfixed at lower levels. The interrupt system still leaves >edge triggered interrupt active after bus_teardown_intr(). > >If you don't know the irq number and don't trust the irq resource to >give it, then there seems to be nothing better than trying all irq >numbers until your irq is found or bus_setup_intr() fails. There can >be up to 193 (?) possible irq numbers on i386's. > >Bruce > > > >Received on Fri Jun 18 2004 - 10:44:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:57 UTC