linux-kernel - RE: [RFC] [PATCH] Adding Intel Moorestown PMIC Battery Driver

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]

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