[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOesGMgB0nVqaxAvuEa2auJ0rBBYQ4fDbG82MwXApYHtt8=Y+g@mail.gmail.com>
Date: Wed, 26 Oct 2011 07:35:19 -0700
From: Olof Johansson <olof@...om.net>
To: Paul Gortmaker <paul.gortmaker@...driver.com>
Cc: Rob Herring <robherring2@...il.com>, Arnd Bergmann <arnd@...db.de>,
Marc Zyngier <marc.zyngier@....com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next failure on tegra due to conflicts between PPI and irq
domain patches and irq.h->module.h include removal
On Wed, Oct 26, 2011 at 7:27 AM, Paul Gortmaker
<paul.gortmaker@...driver.com> wrote:
> On 11-10-25 06:01 PM, Olof Johansson wrote:
>> On Tue, Oct 25, 2011 at 3:00 PM, Rob Herring <robherring2@...il.com> wrote:
>>> Olof,
>>>
>>> On 10/25/2011 04:48 PM, Olof Johansson wrote:
>>>> Hi,
>>>>
>>>> Looks like Marc added new references to irq_start in his PPI patch,
>>>> and Rob removed it in parallel. Also, irq_offset is no longer
>>>> available. Looks like you need to respin your patch, Marc.
>>>>
>>>> arch/arm/common/gic.c: In function 'gic_dist_init':
>>>> arch/arm/common/gic.c:290: error: 'irq_start' undeclared (first use in
>>>> this function)
>>>> arch/arm/common/gic.c:290: error: (Each undeclared identifier is
>>>> reported only once
>>>> arch/arm/common/gic.c:290: error: for each function it appears in.)
>>>> arch/arm/common/gic.c:296: error: 'struct gic_chip_data' has no member
>>>> named 'irq_offset'
>>>
>>> I fixed this and sent a pull request yesterday to Arnd.
>>
>> Ah, oops, forgot to check for already-posted-patches. :) Excellent.
>>
>>
>>>> The second error is because of the change from Paul that removes
>>>> module.h from irq.h:
>>>>
>>>> arch/arm/common/gic.c: In function 'gic_init':
>>>> arch/arm/common/gic.c:620: error: 'THIS_MODULE' undeclared (first use
>>>> in this function)
>>>>
>>>> Looks odd that I should need to include module.h on my own just to use
>>>> irq defines. Paul?
>>>>
>>>
>>> THIS_MODULE is needed by irq.h itself in irq_alloc_descs, so it probably
>>> needs to be added back.
>>
>> Well, the new export.h that defines THIS_MODULE probably needs to be
>> added to irq.h, yes.
>
> No. The whole point of the commit was to avoid nested includes
> as per the commit log:
>
> Also convert the irq_alloc_descs variants to macros, since all
> they really do is is call the __irq_alloc_descs primitive.
> This avoids including export.h and no debug info is lost.
>
> If your file is relating to modular usage such that it is a modular
> provider of interrupt sources and hence uses "THIS_MODULE", then it
> will need export.h in the future. And that macro has nothing whatsoever
> to do with any irq defines; it is used all over the kernel to tie
> structures back to a (possibly modular) code block, just as per the
> use case here in irq.h is.
I strongly disagree.
Why should I have to include export.h to a file that is not ever going
to be built as a module just because I need to include irq.h? That's
nonsense. If irq.h needs it, it should include it on its own.
-Olof
--
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