Marian Balakowicz wrote:
I am enabling and testing PCI on tqm5200 mpc5200 based board where I
faced the following issue.
I am using EEPRO100 PCI card for which there is specific
quirk_e100_interrupt that tries to disable interrupts if
they were left enabled by the firmware. quirk_e100_interrupts() is
called after PCI controller is initialized and before PCI bus
enumeration is performed. On some powerpc platforms, like the one I am
using, PCI controller configuration sets different MEM and IO windows
than those set by firmware. That is why quirk_e100_interrupt() is
causing kernel panic as it tries to read from device BAR0 offets which
at this time point to a invalid PCI window (set by firmware).
The patch below delays the quirk_100_interrupt() to pci_fixup_final
phase, which happens after bus enumeration and before device PCI enable
and device driver initialization - so, it seem to be still a good place
for this quirk. It works fine for me but I only tested it on a tqm5200.
Could someone please help and verify that on other platforms?
will try to do. This sounds indeed like the proper thing to do. Unfortunately I
don't have any NICs to repro this on (allthough I have a ppc box with said
firmware probe method).
Bjorn orignially wrote this patch, perhaps he can comment on the fixup move?
Also, please send a signed-off-by patch so I can push it forward as usual.
Cheers,
Auke
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 01d8f8a..7194074 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1475,7 +1475,7 @@ static void __devinit quirk_e100_interru
iounmap(csr);
}
-DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
quirk_e100_interrupt);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
quirk_e100_interrupt);
static void __devinit fixup_rev1_53c810(struct pci_dev* dev)
{
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
