linux-kernel - Re: [PATCH 8/9] x86: of: irq additions to make drivers/of/* build on x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTiky2-Sr6+0+yyCuo3sVNYB6cxOuSHQkE9LbyynA@mail.gmail.com>
Date:	Mon, 30 Aug 2010 11:31:44 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Stephen Neuendorffer <stephen.neuendorffer@...inx.com>
Cc:	Andres Salomon <dilinger@...ued.net>,
	devicetree-discuss@...ts.ozlabs.org, sparclinux@...r.kernel.org,
	x86@...nel.org, tglx@...utronix.de, mingo@...hat.com,
	hpa@...or.com, cjb@...top.org, Mitch Bradley <wmb@...top.org>,
	pgf@...top.org, linux-kernel@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH 8/9] x86: of: irq additions to make drivers/of/* build on x86

On Mon, Aug 30, 2010 at 9:58 AM, Stephen Neuendorffer
<stephen.neuendorffer@...inx.com> wrote:
>
>
>> -----Original Message-----
>> From: Andres Salomon [mailto:dilinger@...ued.net]
>> Sent: Sunday, August 29, 2010 9:06 PM
>> To: devicetree-discuss@...ts.ozlabs.org
>> Cc: sparclinux@...r.kernel.org; x86@...nel.org; tglx@...utronix.de;
> mingo@...hat.com; hpa@...or.com;
>> cjb@...top.org; Mitch Bradley; pgf@...top.org;
> linux-kernel@...r.kernel.org; davem@...emloft.net;
>> grant.likely@...retlab.ca; Stephen Neuendorffer
>> Subject: [PATCH 8/9] x86: of: irq additions to make drivers/of/* build
> on x86
>>
>>
>> This functionality overlaps with patches previously submitted
>> by Stephen Neuendorffer.  I don't care whose eventually get applied,
>> so long as drivers/of/* becomes buildable on x86.
>>
>> Signed-off-by: Andres Salomon <dilinger@...ued.net>
>
> Agreed..
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@...inx.com>

Okay, I've thought about this problem some more, and I think I've
decided how I want it solved.  Nack on this particular patch because
it adds NO_IRQ to arch/x86/kernel/irq.c (it has been nacked before).
Instead, I'd like the of irq code to be reworked a bit to make this
nicer and isolate the NO_IRQ definition only to the OF irq .c file
(when the arch doesn't explicitly define it).

Right now, there are two files in drivers/of referencing NO_IRQ;
drivers/of/platform.c and drivers/of/irq.c.  platform.c only
references in the context of figuring out how many irqs there are and
populating a resource table.  I'd like to remove that code from
platform.c and add a pair of helper functions to irq.c.  Then the top
of irq.c could conditionally #define NO_IRQ 0 and thereby prevent the
definition leaking out to the rest of the kernel.

Eventually I'll get around to doing this myself, but it would be
helpful to me if either you or Stephen could craft and test a patch.

Perhaps something like:

int of_irq_count(device_node *np)
{
        /* Count and return the number of IRQs. */
}

int of_irq_to_resource_table(device_node *np, struct resource *res, int max)
{
        for (i = 0; i < max; i++; res++)
                if (of_irq_to_resource(np, i, res) == NO_IRQ)
                        break;
        return i;
}

>> ---
>> @@ -275,6 +276,13 @@ void smp_x86_platform_ipi(struct pt_regs *regs)
>>
>>  EXPORT_SYMBOL_GPL(vector_used_by_percpu_irq);
>>
>> +unsigned int irq_create_of_mapping(struct device_node *controller,
>> +             const u32 *intspec, unsigned int intsize)
>> +{
>> +     return intspec[0] + 1;
>> +}
>> +EXPORT_SYMBOL_GPL(irq_create_of_mapping);
>> +

This simplistic implementation is of course non-ideal, but it works as
a stop-gap measure until I've got the irq infrastructure more mature.

g.
--
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/