This function sets up a mapping between an NIC driver’s MiniportISR and MiniportHandleInterrupt functions, already registered with NdisMRegisterMiniport, and the bus-relative vector and level on which its NIC interrupts.
Header file: | Ndis.h |
Windows CE versions: | 2.0 and later |
NDIS_STATUS NdisMRegisterInterrupt(
OUT PNDIS_MINIPORT_INTERRUPT Interrupt,
IN NDIS_HANDLE MiniportAdapterHandle, IN UINT InterruptVector,
IN UINT InterruptLevel, IN BOOLEAN RequestIsr,
IN BOOLEAN SharedInterrupt,
IN NDIS_INTERRUPT_MODE InterruptMode );
Returns one of the following values:
An NIC driver must call this function from its MiniportInitialize function if its NIC generates interrupts. The driver of an NIC that does not generate interrupts calls the NdisMInitializeTimer and NdisMSetPeriodicTimer functions instead of this function.
MiniportInitialize must call NdisMSetAttributes or NdisMSetAttributesEx before calling this function.
MiniportInitialize obtains the bus-relative values passed to this function either from the registry or by calling a bus-type-specific NdisXXX configuration function.
If its call to this function fails, MiniportInitialize releases all resources that it already allocated for its NIC, and then fails initialization for that NIC.
This function distinguishes between the InterruptVector and the InterruptLevel. The InterruptVector is the interrupt line that the card asserts to interrupt the system, and the InterruptLevel is the hardware priority, that is, the DIRQL, of that interrupt assigned by the system. Usually, these values can be assumed to be equal unless the driver writer knows that they are different for a particular NIC or unless the miniport controls more than multiple NICs that share resources in the current platform.
If its NIC can share an IRQ with other devices on the I/O bus, the caller of this function must set both the SharedInterrupt and RequestIsr parameters to TRUE. Such an NIC driver’s MiniportISR function can be called when no interrupt for the NIC is outstanding. In these circumstances, MiniportISR returns FALSE as soon as possible, indicating that the interrupt was not recognized and should leave interrupts enabled on its NIC.
When interrupts are enabled on the NIC, a driver’s MiniportISR function can be called at any time following a successful call to this function, even during initialization. Such a driver’s MiniportInitialize function should not call this function until it has set up all state that the driver needs to handle an interrupt. The MiniportHandleInterrupt function is not queued for subsequent execution if the driver’s MiniportInitialize function is currently executing and an interrupt occurs.
For most drivers of NICs that do not share an IRQ, MiniportISR seldom runs except, possibly, during driver initialization. Such a miniport sets RequestIsr to FALSE when MiniportInitialize calls this function, and such a driver has a MiniportDisableInterrupt function and, possibly, a MiniportEnableInterrupt function. The NDIS library then calls the driver’s MiniportDisableInterrupt function when an interrupt occurs on the NIC and the driver’s MiniportHandleInterrupt function does most of the I/O processing for the interrupt. Before MiniportHandleInterrupt returns control, either NDIS calls MiniportEnableInterrupt or MiniportHandleInterrupt re-enables interrupts on the NIC itself.
Whether a miniport with an ISR sets RequestIsr to TRUE when it calls this function or not, NDIS acknowledges the interrupt to the operating system so that interrupts from other devices are not blocked.
If a miniport sets RequestIsr to TRUE when it calls this function, it must dismiss the interrupt on its NIC by setting the state of the NIC so that it no longer asserts the interrupt. Interrupts can remain enabled on the NIC following the dismissal of the interrupt, or they can be disabled, depending on the design of the driver. The timing of such a dismissal depends on the InterruptMode specified when the driver calls this function, as follows:
When a miniport supports full-duplex sends and receives, NDIS serializes calls to its MiniportISR or MiniportDisableInterrupt function for sends. NDIS separately serializes calls to its MiniportISR or MiniportDisableInterrupt function for all other operations that can cause an interrupt. Calls to the MiniportReset function are both synchronized and synchronous; NDIS prevents all other code paths in a full-duplex miniport from being entered while a device-reset operation is occurring.
If a miniport does not support full-duplex sends and receives, NDIS serializes all calls to the MiniportISR or the MiniportDisableInterrupt function for any NIC that the miniport controls. While such a driver’s MiniportISR or MiniportDisableInterrupt function is processing a particular NIC interrupt, it is not called to handle a second interrupt from the same NIC on another processor in a symmetric multiprocessor ( SMP ) platform.
However, the ISR or MiniportDisableInterrupt function of any driver that controls more than one device can run concurrently in SMP platforms if two of that driver’s devices happen to generate interrupts almost simultaneously and interrupts are enabled on the NIC.
If it is possible that an interrupt can occur while another driver function is accessing resources that can also be accessed from MiniportISR or MiniportDisableInterrupt, the other function must call NdisMSynchronizeWithInterrupt to have the driver-supplied MiniportSynchronizeISR function access the shared resources at DIRQL.
A driver that calls this function runs at IRQL PASSIVE_LEVEL.
NdisMDeregisterInterrupt, NdisMInitializeTimer, NdisMPciAssignResources, NdisMSetAttributes, NdisMSetAttributesEx, NdisMSetPeriodicTimer, NdisMSynchronizeWithInterrupt, NdisOpenConfiguration, NdisReadPciSlotInformation