Re: quirk_e100_interrupt() called too early

["Kok, Auke" <auke-jan.h.kok@intel.com>]

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)
>  {