linux-kernel - Re: [RFC/PATCH 1/2] mfd: twl6030-irq: move to threaded

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]

Date:	Tue, 28 Dec 2010 09:40:03 -0800 (PST)
From:	David Brownell <david-b@...bell.net>
To:	Felipe Balbi <balbi@...com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC/PATCH 1/2] mfd: twl6030-irq: move to threaded_irq



--- On Tue, 12/28/10, Mark Brown <broonie@...nsource.wolfsonmicro.com> wrote:

> F

> You shouldn't need this any more; the driver used to be
> faffing around
> with this because it wasn't using genirq for
> this in the past.

Originally it couldn't, since genirq didn't
support threaded IRQ handling...

...

> 
> Simiarly here as far as I know; the original code predates
> genirq
> support for this so is doing some hairy stuff that is no
> longer
> required and may actually be harmful.
> 
> What I'd expect to see from a conversion like this would be
> that most of
> the locking/IRQ management stuff would be dropped

I'd expect that genirq solve all the issues and
that its support be used.  That's not the same
as dropping anything except the initial code to
handle what genirq didn't ... some locking/etc
would still mostly need doing, but where genirq
now handles it, that'd be preferable.
 and the
> bus_lock() and
> bus_sync_unlock() operations would be implemented.
h
ISTR maybe four or five genirq updates in the
area of threaded IRQ management, added so that
issues the twl4030 driver needed to be solved
could be solved in generic ways.

The first was just having threaded IRQ handlers,
and another was I think removing the initial
quick'n'dirty thread-per-irq restriction; there
was no point in having a few dozen IRQ threads
in e.g. a twl4030 driver, since two could never
do constructive work concurrently.

I'm glad to see this conversion finally start.
Even if all the threaded IRQ hooks don't get used
to best advantage, it'll be an improvement.

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