linux-kernel - Re: [Question] Should we make the primary interrupt handler configurable for regmap_add_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 for Android: free password hash cracker in your pocket

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

Message-ID: <20140116140153.GC17314@sirena.org.uk>
Date:	Thu, 16 Jan 2014 14:01:53 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Yi Zhang <yizhang.mrvl@...il.com>
Cc:	Yi Zhang <yizhang@...vell.com>, hongfeng@...vell.com,
	linux-kernel@...r.kernel.org, zhouqiao@...vell.com
Subject: Re: [Question] Should we make the primary interrupt handler
 configurable for regmap_add_irq_chip()?

On Thu, Jan 16, 2014 at 07:33:13PM +0800, Yi Zhang wrote:
> 2014/1/15 Mark Brown <broonie@...nel.org>:
> > On Sat, Jan 11, 2014 at 12:15:21PM +0800, Yi Zhang wrote:

> >> I met a scenario:
> >> As soon as the interrupt is triggered, a wakelock is needed to be held
> >> until the threaded handler finishes,
> >> I think we may hold it in the primary interrupt handler, but now it's
> >> NULL by default;

> > This sounds like something we should just support in the core, though to

> Sorry, I'm not clear about this, you mean that this has been supported
> in regmap framework?
> I searched but didn't find related mail about this, could you please
> kindly point out the mail loop?
> thanks very much;

I'm saying we should support it in the core rather than providing a way
to override the handlers - it seems like it'll be sufficiently common
that we'll rapidly end up with multiple implementations anyway.  It
isn't currently supported in the core though, someone would need to
write that code.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)