linux-kernel - Re: [PATCH v3] input: add driver support for Sharp gp2ap002a00f proximity sensor

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]

Message-ID: <20111117214343.GB31479@core.coreip.homeip.net>
Date:	Thu, 17 Nov 2011 13:43:51 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	oskar.andero@...yericsson.com
Cc:	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jic23@....ac.uk" <jic23@....ac.uk>,
	"aghayal@...eaurora.org" <aghayal@...eaurora.org>,
	"Cavin, Courtney" <Courtney.Cavin@...yericsson.com>,
	Shubhrajyoti <shubhrajyoti@...com>
Subject: Re: [PATCH v3] input: add driver support for Sharp gp2ap002a00f
 proximity sensor

On Thu, Nov 17, 2011 at 12:22:19PM +0100, oskar.andero@...yericsson.com wrote:
> Hi Dmitry,
> 
> On 13:18 Wed 16 Nov     , Oskar Andero wrote:
> > On 12:28 Wed 16 Nov     , Shubhrajyoti wrote:
> > > On Wednesday 16 November 2011 04:07 PM, oskar.andero@...yericsson.com
> > > wrote:
> > > > On 19:29 Tue 15 Nov     , Dmitry Torokhov wrote:
> > > >> On Tue, Nov 15, 2011 at 01:53:52PM +0100, oskar.andero@...yericsson.com wrote:
> > > >>> On 10:43 Tue 15 Nov     , Dmitry Torokhov wrote:
> > > >>>> On Tue, Nov 15, 2011 at 10:26:00AM +0100, oskar.andero@...yericsson.com wrote:
> > > >>>>> From: Courtney Cavin <courtney.cavin@...yericsson.com>
> > > >>>>> +
> > > >>>>> +#ifdef CONFIG_PM_SLEEP
> > > >>>>> +static int gp2a_suspend(struct device *dev)
> > > >>>>> +{
> > > >>>>> +	struct i2c_client *client = to_i2c_client(dev);
> > > >>>>> +	struct gp2a_data *dt = i2c_get_clientdata(client);
> > > >>>>> +	int error;
> > > >>>>> +
> > > >>>>> +	mutex_lock(&dt->device->mutex);
> > > >>>>> +
> > > >>>>> +	if (dt->device->users) {
> > > >>>>> +		if (device_may_wakeup(&client->dev)) {
> > > >>>>> +			enable_irq_wake(client->irq);
> > > >>>> I think this part should happen regardless of whether device has users,
> > > >>>> only non wakeup source case needs it.
> > > >>> Hmm.. why would one want to enable irq_wake when there are no users?
> > > >>> Wouldn't this cause the device to wakeup at every irq and report an
> > > >>> switch event that no one listens to?
> > > >> You are suspending the system and want to have this device as a wakeup
> > > >> source. Note: not wake up _device_ at every IRQ but wake up the whole
> > > >> _system_ when device generates an IRQ while system is asleep.
> > > >> It does not matter whether there are users for the events; you
> > > >> want the system to wake up.
> > > >>
> > > >> At least this is the usual semantics.
> > > > I see you point. However, the way we use the proximity sensor we can only wake up
> > > > the system when we have an application that is actually interested in the change.
> > > > This is for power save reasons.
> > > > If we use the "usual semantic", we would wake up the system at every proximity
> > > > detection regardlessly. For instance, I wouldn't want to wake up a cell phone laying
> > > > on the desk when I put my hand over it. That would hurt the battery time.
> > > Even in that case it shouldn't harm the power if no user is there the
> > > close would have been called
> > > and you should  be in the shut down mode? Am I missing something?
> > 
> > You are right - the chip will only generate interrupts when it's opened, so the case
> > I described shouldn't actually be a problem. However, does it make sense to enable irq_wake
> > for a device that will never generate interrupts?
> 
> Do you have any input on my question above? My suggestion is to keep the code as it is,
> unless you see a reason for enabling wake_irq on an irq that will never happen.

So let me get it straight - with your particular device (as in phone)
you do not expect the sensor to be used as a wakeup source for the
system. If this is correct then it does not really matter what suspend
and resume callbacks are doing. Other devices using the same sensor
might have different requirements, including being a wakeup source for
the system.

Thanks.

-- 
Dmitry
--
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/