https://github.com/torvalds/linux
Revision a69bf3c5b49ef488970c74e26ba0ec12f08491c2 authored by Douglas Miller on 04 March 2016, 21:36:56 UTC, committed by David S. Miller on 07 March 2016, 20:18:31 UTC
The adapter->pcicfg resource is either mapped via pci_iomap() or
derived from adapter->db. During be_remove() this resource was ignored
and so could remain mapped after remove.

Add a flag to track whether adapter->pcicfg was mapped or not, then
use that flag in be_unmap_pci_bars() to unmap if required.

Fixes: 25848c901 ("use PCI MMIO read instead of config read for errors")

Signed-off-by: Douglas Miller <dougmill@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
1 parent cec0556
Raw File
Tip revision: a69bf3c5b49ef488970c74e26ba0ec12f08491c2 authored by Douglas Miller on 04 March 2016, 21:36:56 UTC
be2net: Don't leak iomapped memory on removal.
Tip revision: a69bf3c
IRQ.txt
What is an IRQ?

An IRQ is an interrupt request from a device.
Currently they can come in over a pin, or over a packet.
Several devices may be connected to the same pin thus
sharing an IRQ.

An IRQ number is a kernel identifier used to talk about a hardware
interrupt source.  Typically this is an index into the global irq_desc
array, but except for what linux/interrupt.h implements the details
are architecture specific.

An IRQ number is an enumeration of the possible interrupt sources on a
machine.  Typically what is enumerated is the number of input pins on
all of the interrupt controller in the system.  In the case of ISA
what is enumerated are the 16 input pins on the two i8259 interrupt
controllers.

Architectures can assign additional meaning to the IRQ numbers, and
are encouraged to in the case  where there is any manual configuration
of the hardware involved.  The ISA IRQs are a classic example of
assigning this kind of additional meaning.
back to top