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:	Fri, 11 Mar 2011 11:02:17 -0800
From:	Abhijeet Dharmapurikar <adharmap@...eaurora.org>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	davidb@...eaurora.org, "David S. Miller" <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bryan Huntsman <bryanh@...eaurora.org>,
	Daniel Walker <dwalker@...o99.com>,
	David Collins <collinsd@...eaurora.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Joe Perches <joe@...ches.com>,
	Russell King <linux@....linux.org.uk>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Stepan Moskovchenko <stepanm@...eaurora.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Linus Walleij <linux.walleij@...rricsson.com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [Qualcomm PM8921 MFD v2 2/6] mfd: pm8xxx: Add irq support


>> Yes however while updating the code I noticed that I would need to keep
>> account of all the interrupts enabled and all the interrupts marked wakeup.
>> This aids in switching to the wakeup set in the suspend callback and the
>> enabled set in the resume callback. I will update the resume callback to
>> enable the interrupts in irqs_allowed(the local state storage) in the next
>> patch (my current patch does not do that).
>>
>> IOW I need to keep the local state storage.
> 
> Wrong. The interrupts are disabled and reenabled by the core code and
> not by some extra suspend/resume callbacks in your driver. The core
> checks those marked as IRQ_WAKE, the wake callback to the irq chip is
> only there if you need to set up some hardware register in order to
> make the wake functionality work. So again, you don't need local state
> as the core tracks the state for you.

Help me understand this, the core code calls disable on all the 
interrupts while going to suspend. Notice that I have no disable 
callback, which means those interrupts remain unmasked.

I could have a situation, when the system(a mobile phone) goes to 
suspend we dont want to wake it up because of unnecessary interrupts. A 
good example is, we want to wakeup the phone if the battery goes low, 
but dont want to wake it up if an acceleromter interrupt triggers. The 
drivers respectively mark the battery low interrupt as wakeup and the 
accelerometer interrupt as a non-wake up interrupt. Assume both of them 
are edge triggered interrupts.

The genirq code does not mask the interrupt while going to suspend, it 
only calls disable(), which I understand should not mask the interrupt 
for check_wakeup_irqs() to work.

If I don't mask that accelerometer interrupts in the interrupt 
controller's suspend() the phone will wakeup every time the user moves 
around, draining the battery unnecessarily.

One might say that the accelerometer should be deactivated in the 
suspend callback of the accelerometer driver. Yes this can be done and 
we will not see an interrupt while suspended. However not all hardware 
can be deactivated like that. There are some devices which simply 
interrupt and the only way to keep from waking up is masking their 
interrupts.

How do you suggest I mask the accelerometer interrupt?

Abhijeet
--
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm 
Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ