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. BruceReceived on Thu Jun 17 2004 - 21:51:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:57 UTC