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] [day] [month] [year] [list]
Message-ID: <175E0F9A9EFCEA46A65F5552BB057298046D05F9A2@bgsmsx502.gar.corp.intel.com>
Date:	Sat, 13 Feb 2010 20:05:29 +0530
From:	"Mahalingam, Nithish" <nithish.mahalingam@...el.com>
To:	"avorontsov@...mvista.com" <avorontsov@...mvista.com>
CC:	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"cbou@...l.ru" <cbou@...l.ru>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC] [PATCH] Adding Intel Moorestown PMIC Battery Driver

Hi Anton,

First of all apologize for not sticking to my word to get back with
the patch as promised. Got tied up with some important work and could
not spend time on this patch.

I have started making changes today and will be testing it out after
the weekend. Will post the patch for review by mid next week for sure.

OK now to a question I had while working on the patch:

>>> +       schedule_work(&pbi->handler);
>> 
>> I think you can use threaded irq for this.
>> 
>> See documentation for request_threaded_irq() in kernel/irq/manage.c.
>> And as an example of usage see drivers/mfd/wm8350-irq.c.
> 
> Haa that is useful information... completely missed to read about this 
> feature. Will modify the code to make use of threaded IRQ.

I have a very peculiar case - My hardware muxes 8 different types of 
battery interrupts as one before forwarding it. I do the interrupt 
de-muxing in the driver to find its real source; because I do this I 
had used workqueue to make sure I do not keep the battery interrupt 
source disabled for a long time and won't potential miss a battery 
interrupt.
I was reading the request_threaded_irq code and found that only 
when the threaded function returns interrupt should be re-enabled 
(as it is suggested in the APIs function comment). Now if I do this, 
won't I potential miss a interrupt?

Also I failed to understand what exact scenario request_threaded_irq 
is useful over having a workqueue spawned inside a interrupt handler? 
Is it only when you want to hold the interrupt EOI until the threaded  
function returns?

Please shout back if I am making some stupid assumptions here.

Regards,
Nithish Mahalingam

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ