[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aday7789dkk.fsf@cisco.com>
Date: Sun, 20 Apr 2008 18:55:23 -0700
From: Roland Dreier <rdreier@...co.com>
To: Dave Olson <dave.olson@...gic.com>
Cc: Ingo Molnar <mingo@...e.hu>,
Ralph Campbell <ralph.campbell@...gic.com>,
akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
linux-kernel@...r.kernel.org, general@...ts.openfabrics.org
Subject: Re: [ofa-general] Re: [GIT PULL] please pull infiniband.git
> | Not sure I really follow this response... ipath_driver.c has
> |
> | case PCI_DEVICE_ID_INFINIPATH_7220:
> | #ifndef CONFIG_PCI_MSI
> | ipath_dbg("CONFIG_PCI_MSI is not enabled, "
> | "using IntX for unit %u\n", dd->ipath_unit);
> | #endif
> | ipath_init_iba7220_funcs(dd);
> | break;
> |
> | so clearly ipath_init_iba7220_funcs() was intended to be built and used
> | even if CONFIG_PCI_MSI was not defined. From the code it looks like all
> | should work fine if PCI_MSI is not set, so I don't know what you mean
> | about conditional checks.
>
> Actually, it wasn't. It was a late cleanup for another problem, and
> we didn't worry about the other issue, and should have.
Sorry, I still don't follow. What is the antecedent of "it"? What was
"the other issue"?
I'm not sure I know the right fix for the build breakage. It seems
there are two possibilities:
- build the iba7220 support unconditionally (the patch I posted).
- change the case statement I quoted above so that the
ipath_init_iba7220_funcs() call is inside the #ifdef block (and add
an error message if CONFIG_PCI_MSI is not defined, as for the 6120
block in the same case statement).
Since it seems iba7220 works with INTx interrupts, the first choice
makes the most sense to me.
And since all the pci_msi functions have stubs that just fail
unconditionally if CONFIG_PCI_MSI is not defined, it seems we can remove
the #ifdef CONFIG_PCI_MSI from the iba7220 files.
And given that at least some device support works even if neither
PCI_MSI nor HT_IRQ is defined, then it makes sense to me to remove that
Kconfig dependency.
If I have something wrong, please let me know.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists