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 17:45:03 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	David Brownell <david-b@...bell.net>
Cc:	Felipe Balbi <balbi@...com>,
	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, Dec 28, 2010 at 09:40:03AM -0800, David Brownell wrote:

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

It should solve everything - there's rather a lot of I2C/SPI connected
MFDs using genirq fully now without any hassle, the APIs are really
straightforward and easy to use.

>  and the
> > bus_lock() and
> > bus_sync_unlock() operations would be implemented.

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

Yup - the main one on top of threaded IRQs was the bus_lock() and
bus_sync_unlock() methods.

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

The thread per IRQ thing is dealt with too, the secondary IRQs share the
thread used for demux.
--
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/