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

From: Zwane Mwaikambo (zwane_at_linuxpower.ca)
Date: 09/30/04

  • Next message: Stephen Tweedie: "[Patch 0/10]: Cleanup online reservations for 2.6.9-rc2-mm4." 
    Date:	Thu, 30 Sep 2004 16:03:56 +0300 (EAT)
To: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>

    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-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Stephen Tweedie: "[Patch 0/10]: Cleanup online reservations for 2.6.9-rc2-mm4."

    Relevant Pages

    • Re: ADI Blackfin patch for kernel 2.6.14
      ... > That being said, a 1.6MB patch is a bit hard to review, mainly because it ... We don't want to merge an arch and then have it bitrot. ... > extern decls should always go in header files. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] missing includes from infiniband merge
      ... The only thing I like to see is minimal suprise. ... counterpart. ... A grep shows that most architectures include almost the same header files ... linux/uaccess.h counter part and no arch specific dependencies. ...
      (Linux-Kernel)
    • [PATCH 1/5] kbuild: prepare headers_* for arch/$ARCH/include
      ... Factor out the headers_*_all support to a seperate ... shell script and add support for arch specific ... @echo ' checkstack - Generate a list of stack hogs' ... @echo ' includecheck - Check for duplicate included header files' ...
      (Linux-Kernel)
    • [PATCH 10/24] kbuild: prepare headers_* for arch/$ARCH/include
      ... Factor out the headers_*_all support to a seperate ... shell script and add support for arch specific ... @echo ' checkstack - Generate a list of stack hogs' ... @echo ' includecheck - Check for duplicate included header files' ...
      (Linux-Kernel)
    • Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE
      ... this case is useless on ppc... ... completely instead and define it's arch impl. ... ptep_set_dirty_accessedresponsibility to do the TLB flush if ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)