linux-kernel - Re: [PATCH] gpio: Emma Mobile GPIO driver V2

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 17 May 2012 09:41:25 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Magnus Damm <magnus.damm@...il.com>, linux-kernel@...r.kernel.org,
	rjw@...k.pl, linus.walleij@...ricsson.com,
	linux-sh@...r.kernel.org, horms@...ge.net.au,
	grant.likely@...retlab.ca, olof@...om.net
Subject: Re: [PATCH] gpio: Emma Mobile GPIO driver V2

On Wed, May 16, 2012 at 12:09:03PM +0000, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Magnus Damm wrote:
> > > irq_domain_add_legacy() exists for existing static ranges, which there is
> > > really no reason to be adding in new board/platform support. You don't
> > > have to worry about virq overlap since irq_create_mapping() already wraps
> > > on top of irq_alloc_desc_xxx() for lookup.
> > 
> > So I intentionally made use of the legacy domain in the non-DT case.
> > This because I want to let the SoC code set the static IRQ ranges via
> > platform data.
> 
> I think it's generally better to use just one code path for both cases,
> if you need both DT and non-DT support, which means you would always
> use irq_domain_add_legacy. Once you have the final patch to convert it
> to DT, you can remove the legacy domain and just convert it to linear.
> 
That's a bit short sighted. There are going to be plenty of cases where
we can tie in IRQ domains and will make use of it both with and without
DT, and there is very little cause for forcing manual irq_desc
allocation/freeing up the chain when the IRQ domain code can handle it
just fine.

The one area that I see being problematic with IRQ domains at the moment
is IORESOURCE_IRQ. In the 'legacy' cases this maps out to the hwirq,
while in the non-legacy cases it works out to a virq mapping that's
lazily inserted by of_irq_to_resource_table() in of_device_alloc().

In adding irq domain support for the sh intc subsystem I hacked up some
prototype code for doing an in-place update of IORESOURCE_IRQ resources
hanging off platform devices that does the hwirq->virq translation and it
seems to work fine, albeit hacky, and something I would rather avoid. On
the other hand, there's no need for that either if we support a 1:1 hwirq
to virq mapping where possible, which is fairly easy to do by just trying
to fetch a virq with irq_alloc_desc_at() before falling back on the
existing virq hinting logic in irq_create_mapping(). We can easily or a
flag in to the revmap type that denotes the 'static' nature of the domain
to inhibit irq_alloc_desc_from() usage in domains with 1:1 mappings.

In any event, it looks like irq domains needs some more work for the
non-DT case before it can really be useful. Creating arbitrary static
mappings to shoe-horn a driver in to DT + non-DT shape through a legacy
mapping seems pretty absurd, though.

I'll do some more hacking on it and see what I come up with, but I'm
certainly not going to be maintaining my own radix tree on the side and
wrapping in to a legacy domain for the sh intc case when all of the
support infrastructure is already extant in the irqdomain code.
--
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/