Re: [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation support [2/3]

From: Zwane Mwaikambo <zwane_at_linuxpower.ca>
Date: 2004-09-30 23:03:56
On Thu, 30 Sep 2004, Kenji Kaneshige wrote:

> Zwane Mwaikambo wrote:
> > 
> > Ok i think i may have not conveyed my meaning properly, my mistake. What i
> > think would be better is if the architectures which have no-op
> > acpi_unregister_gsi to declare them as static inline in header files. For
> > architectures (such as ia64) which have a functional acpi_unregister_gsi, we
> > can declare them in a .c file with the proper exports etc.
> > 
> 
> Now I (maybe) properly understand what you mean :-). But I still have one
> concern about your idea.
> 
> For architectures which have a functional acpi_unregister_gsi, we need to
> declare "extern void acpi_unregister_gsi(int gsi);" in include/linux/acpi.h
> that is common to all architectures. I think include/linux/acpi.h is the
> best place to declare it because acpi_register_gsi(), opposite portion of
> acpi_unregister_gsi(), is declared in it. On the other hand, for archtectures
> that have no-op acpi_unregister_gsi(), acpi_unregister_gsi() is defined as
> static inline function in arch specific header files. This looks not natural
> to me.

Can't you declare "extern void acpi_unregister_gsi(int gsi)" in 
include/asm/acpi.h? That way it stays arch specific and you don't have the 
conflicting declarations. You can also move acpi_unregister_gsi into arch 
specific headers too.

Thanks,
	Zwane
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Thu Sep 30 09:13:53 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:31 EST