On 3/30/10 12:43 AM, Myles Watson wrote:
On Mon, Mar 29, 2010 at 4:40 PM, Stefan Reinauer <stepan@coresystems.de mailto:stepan@coresystems.de> wrote:
On 3/30/10 12:35 AM, Stefan Reinauer wrote:On 3/30/10 12:15 AM, Myles Watson wrote:Modified: trunk/src/arch/i386/include/arch/pirq_routing.h ============================================================================== --- trunk/src/arch/i386/include/arch/pirq_routing.h Mon Mar 29 23:56:26 2010 (r5318) +++ trunk/src/arch/i386/include/arch/pirq_routing.h Tue Mar 30 00:05:26 2010 (r5319) @@ -18,9 +18,8 @@ #if defined(CONFIG_IRQ_SLOT_COUNT) #define IRQ_SLOTS_COUNT CONFIG_IRQ_SLOT_COUNT -#elif (__GNUC__ < 3) -#define IRQ_SLOTS_COUNT 1 #else +#warning "No IRQ_SLOT_COUNT in Kconfig." #define IRQ_SLOTS_COUNT #endif I think we should get rid of IRQ_SLOTS_COUNT and move the error into Kconfig. The added warning is very similar to one in pirq_routing.cI like that much better... do you have a patch in mind?Hm.. how do we error in Kconfig? Is there a way to do that at all? I think we didn't use this before...I was thinking about making HAVE_PIRQ_TABLE depend on CONFIG_IRQ_SLOT_COUNT
Then when someone ported Coreboot to a board they'd set it correctly. We could tell from abuild results how many boards have HAVE_PIRQ_TABLE set and not CONFIG_IRQ_SLOT_COUNT.
I'd prefer the build failing if someone sets HAVE_PIRQ_TABLE without CONFIG_IRQ_SLOT_COUNT (unless we can create CONFIG_IRQ_SLOT_COUNT on the fly which would be much, much better)
Silently disable HAVE_PIRQ_TABLE if CONFIG_IRQ_SLOT_COUNT is not there would maybe lead to people enabling HAVE_PIRQ_TABLE and wondering or not (more likely not) why there is no PIRQ table. At least on ACPI systems, PIRQ is the untested path anyways..
Stefan