linux-kernel - Re: [RFC 13/14] irq_domain: Remove 'new' irq

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: <4F0F8093.7010902@gmail.com>
Date:	Thu, 12 Jan 2012 18:53:39 -0600
From:	Rob Herring <robherring2@...il.com>
To:	Grant Likely <grant.likely@...retlab.ca>
CC:	linux-kernel@...r.kernel.org,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linuxppc-dev@...ts.ozlabs.org,
	Russell King <linux@....linux.org.uk>, sfr@...b.auug.org.au,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of
 the ppc one

On 01/12/2012 06:47 PM, Grant Likely wrote:
> On Thu, Jan 12, 2012 at 5:31 PM, Rob Herring <robherring2@...il.com> wrote:
>> Adding lakml...
>>
>> On 01/11/2012 03:27 PM, Grant Likely wrote:
>>> On Wed, Jan 11, 2012 at 2:15 PM, Rob Herring <robherring2@...il.com> wrote:
>>>> Grant,
>>>>
>>>> On 01/11/2012 02:22 PM, Grant Likely wrote:
>>>>> This patch removes the simplistic implementation of irq_domains and enables
>>>>> the powerpc infrastructure for all irq_domain users.  The powerpc
>>>>> infrastructure includes support for complex mappings between Linux and
>>>>> hardware irq numbers, and can manage allocation of irq_descs.
>>>>>
>>>>> This patch also converts the few users of irq_domain_add()/irq_domain_del()
>>>>> to call irq_domain_add_legacy() instead.
>>>>
>>>> So what is the non-legacy way? Legacy implies we don't want to do it
>>>> that way. I guess until we remove all non-DT platforms with GIC we are
>>>> stuck with legacy. That seems like it could be a ways out until we get
>>>> there.
>>>
>>> Non-legacy is letting the irq_domain manage the irq_desc allocations.
>>> Some of the controllers will be easy to convert, some will be more
>>> difficult.  The primary thing that really blocks getting away from the
>>> legacy method is anything that expects hardcoded #defined irq numbers.
>>>  The goal is to convert all users over to the linear revmap method.
>>>
>>
>> So I gave this a spin on highbank. I ran into a couple problems.
>>
>> I had to revert "irqdesc: Consolidate irq reservation logic" which is in
>> your branch, but not this series. irq_alloc_desc_from was returning -EEXIST.
> 
> Hmmm... I thought I sorted that out.  Thanks for letting me know.
> 
>>
>> The GIC code did not work which I think is specific to using gic_of_init
>> which makes irq_start = -1. With that it still doesn't work. It dies in
>> gic_set_type... I've found one problem which I'll reply inline to, but I
>> think this is a dead end path anyway.
> 
> Haha, I'm not surprised.  That last patch was only compile tested on
> platforms using the gic.  I'm not surprised that I flubbed it.
> 
>> You have removed the irq_alloc_descs call from the GIC which is a step
>> backwards. Several of the ARM DT enabled platforms are at the point they
>> can fully support dynamic virq base for each irqchip. I changed the
>> domain from legacy to linear and got things working.
>> The issue with
> 
> I hadn't actually intended to remove the irq_alloc_descs in this
> patch.  That was a leftover hunk from when I was playing with going
> straight to irq_domain_add_linear().  For this specific patch, I'll
> put the alloc back in and test it that way.  A follow-on patch can do
> a proper conversion to the linear revmap.
> 
>> linear is for SPARSE_IRQ. The default behavior on ARM for SPARSE_IRQ is
>> all nr_irqs are allocated at boot time before any controller is
>> initialized. The only platform with a GIC and requiring SPARSE_IRQ is
>> shmobile, but it is also the only one that calls irq_alloc_desc
>> functions for it's interrupts. So I think we are okay there. The problem
>> occurs when enabling SPARSE_IRQ for a non-DT platform with a GIC and
>> with irqchips that don't call irq_alloc_desc for their irqs. IMHO, this
>> should be an okay trade-off. There's no advantage to enabling SPARSE_IRQ
>> on ARM for platforms that don't require it. All the platforms with a GIC
>> have active work to convert to DT (except shmobile which I think is
>> okay), so it's a temporary issue.
> 
> Actually, I believe Thomas' long term goal is to always enable
> SPARSE_IRQ and remove the option entirely, so it should still be
> properly resolved. I'll take a look next week if I don't get to it
> tomorrow.  I need to resurrect my vexpress qemu test environment so I
> can test the permutations.
> 

Agreed. I think that is the path to the removing include of mach/irqs.h
as well, and I have a patch series to do just that when SPARSE_IRQ is
enabled. It also has the problem of breaking platforms which don't NEED
to enable SPARSE_IRQ. I'll try to get it sent out soon.

Rob

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