[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4EA82015.4020600@windriver.com>
Date: Wed, 26 Oct 2011 10:58:29 -0400
From: Paul Gortmaker <paul.gortmaker@...driver.com>
To: Olof Johansson <olof@...om.net>
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 11-10-26 10:35 AM, Olof Johansson wrote:
> 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
You won't. Unless you use irq_alloc_descs. Also export.h isn't just
for modules. It is for code that in some way is exporting infrastructure
to allow modular infrastructure to exist. So there is lots of files that
will include export.h that in turn are not modules themselves. That was
largely the point.
Thanks,
Paul.
> 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