Kenji Kaneshige wrote:
> - Changed acpi_pci_irq_disable() to leave 'dev->irq' as it
> is. Clearing 'dev->irq' by some magic constant
> (e.g. PCI_UNDEFINED_IRQ) is TBD.
This may not be safe with CONFIG_PCI_MSI, you may want to verify against
that if you already haven't.
> +acpi_unregister_gsi (unsigned int irq)
> +{
> +}
> +EXPORT_SYMBOL(acpi_unregister_gsi);
Why not just make these static inlines in header files? Since you're on
this, how about making irq_desc and friends dynamic too?
Thanks,
Zwane
On Sat, 25 Sep 2004, Zwane Mwaikambo wrote:
> Kenji Kaneshige wrote:
>
> > - Changed acpi_pci_irq_disable() to leave 'dev->irq' as it
> > is. Clearing 'dev->irq' by some magic constant
> > (e.g. PCI_UNDEFINED_IRQ) is TBD.
>
> This may not be safe with CONFIG_PCI_MSI, you may want to verify against
> that if you already haven't.
>
> > +acpi_unregister_gsi (unsigned int irq)
> > +{
> > +}
> > +EXPORT_SYMBOL(acpi_unregister_gsi);
>
> Why not just make these static inlines in header files? Since you're on
> this, how about making irq_desc and friends dynamic too?
Sorry, i broke Cc.
Zwane Mwaikambo wrote:
> On Sat, 25 Sep 2004, Zwane Mwaikambo wrote:
>
>> Kenji Kaneshige wrote:
>>
>> > - Changed acpi_pci_irq_disable() to leave 'dev->irq' as it
>> > is. Clearing 'dev->irq' by some magic constant
>> > (e.g. PCI_UNDEFINED_IRQ) is TBD.
>>
>> This may not be safe with CONFIG_PCI_MSI, you may want to verify against
>> that if you already haven't.
>>
Thank you for commemts.
You are right. If the linux IRQ number is allocated by MSI code,
clearing 'dev->irq' would cause a problem. So we need to consider
clearing 'dev->irq' carefully.
The latest patch doesn't clear 'dev->irq' so far.
>> > +acpi_unregister_gsi (unsigned int irq)
>> > +{
>> > +}
>> > +EXPORT_SYMBOL(acpi_unregister_gsi);
>>
>> Why not just make these static inlines in header files? Since you're on
>> this, how about making irq_desc and friends dynamic too?
>
> Sorry, i broke Cc.
>
I'm not quite sure what you are saying, but my idea is defining
acpi_unregister_gsi() as a opposite part of acpi_register_gsi().
Acpi_register_gsi() is defined for each arch (i386, ia64), so
acpi_unregister_gsi() is defined for each i386 and ia64 too.
Thanks,
Kenji Kaneshige
On Mon, 27 Sep 2004, Kenji Kaneshige wrote:
> > > Why not just make these static inlines in header files? Since you're on
> > > this, how about making irq_desc and friends dynamic too?
>
> I'm not quite sure what you are saying, but my idea is defining
> acpi_unregister_gsi() as a opposite part of acpi_register_gsi().
> Acpi_register_gsi() is defined for each arch (i386, ia64), so
> acpi_unregister_gsi() is defined for each i386 and ia64 too.
Well i meant can't you define them in a header file as follows;
static void inline acpi_unregister_gsi (unsigned int irq)
{
}
An advantage is that it saves memory since you don't also have to create
the extra data objects for the exported symbol. But really you don't have
to export something which does nothing.
Thanks,
Zwane
Zwane Mwaikambo wrote:
> On Mon, 27 Sep 2004, Kenji Kaneshige wrote:
>
>> > > Why not just make these static inlines in header files? Since you're on
>> > > this, how about making irq_desc and friends dynamic too?
>>
>> I'm not quite sure what you are saying, but my idea is defining
>> acpi_unregister_gsi() as a opposite part of acpi_register_gsi().
>> Acpi_register_gsi() is defined for each arch (i386, ia64), so
>> acpi_unregister_gsi() is defined for each i386 and ia64 too.
>
> Well i meant can't you define them in a header file as follows;
>
> static void inline acpi_unregister_gsi (unsigned int irq)
> {
> }
>
> An advantage is that it saves memory since you don't also have to create
> the extra data objects for the exported symbol. But really you don't have
> to export something which does nothing.
>
Hi Zwane,
I understand what you mean. It looks good to me.
I'll update my patch.
Thanks,
Kenji Kaneshige
Hi Zwane,
I'm trying to update my patch based on the feedback from you. Updated
patch defines acpi_unregister_gsi() in both include/asm-i386/acpi.h
and include/asm-ia64/acpi.h. But now I'm having one concern about it.
Some arch specific functions would be called from acpi_unregister_gsi()
when it is implemented. But include/asm-xxx/acpi.h is included before
many other header files, so many 'implicit declaration of function xxx'
warning message would be appeared. These warning messages are disappeared
if we declare all functions called by acpi_unregister_gsi() also in
include/asm-xxx/acpi.h. But I don't like this approach very much.
After all, now I think it is better not to define acpi_unregister_gsi()
in header files.
How do you think?
Thanks,
Kenji Kaneshige
Zwane Mwaikambo wrote:
> On Mon, 27 Sep 2004, Kenji Kaneshige wrote:
>
>> > > Why not just make these static inlines in header files? Since you're on
>> > > this, how about making irq_desc and friends dynamic too?
>>
>> I'm not quite sure what you are saying, but my idea is defining
>> acpi_unregister_gsi() as a opposite part of acpi_register_gsi().
>> Acpi_register_gsi() is defined for each arch (i386, ia64), so
>> acpi_unregister_gsi() is defined for each i386 and ia64 too.
>
> Well i meant can't you define them in a header file as follows;
>
> static void inline acpi_unregister_gsi (unsigned int irq)
> {
> }
>
> An advantage is that it saves memory since you don't also have to create
> the extra data objects for the exported symbol. But really you don't have
> to export something which does nothing.
>
> Thanks,
> Zwane
>
On Wed, 29 Sep 2004, Kenji Kaneshige wrote:
> I'm trying to update my patch based on the feedback from you. Updated
> patch defines acpi_unregister_gsi() in both include/asm-i386/acpi.h
> and include/asm-ia64/acpi.h. But now I'm having one concern about it.
>
> Some arch specific functions would be called from acpi_unregister_gsi()
> when it is implemented. But include/asm-xxx/acpi.h is included before
> many other header files, so many 'implicit declaration of function xxx'
> warning message would be appeared. These warning messages are disappeared
> if we declare all functions called by acpi_unregister_gsi() also in
> include/asm-xxx/acpi.h. But I don't like this approach very much.
>
> After all, now I think it is better not to define acpi_unregister_gsi()
> in header files.
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.
Thanks Kenji and sorry for the confusion.
Zwane
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.
How do you think?
Thanks,
Kenji Kaneshige
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
Zwane Mwaikambo wrote:
>
> 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.
>
OK. I'll update my patch based on your feedback.
Thanks,
Kenji Kaneshige