public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>,
	linux-kernel@vger.kernel.org, dbasehore@google.com,
	dianders@chromium.org,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	gwendal@chromium.org, Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH v2] input: cros_ec_keyb: Report wakeup events
Date: Mon, 3 Apr 2017 13:53:53 -0700	[thread overview]
Message-ID: <20170403205352.GA138246@google.com> (raw)
In-Reply-To: <20170403184336.GD34530@dtor-ws>

+ others

On Mon, Apr 03, 2017 at 11:43:36AM -0700, Dmitry Torokhov wrote:
> On Sun, Apr 02, 2017 at 08:07:39AM +0800, Jeffy Chen wrote:
> > Report wakeup events when process events.
> > 
> > Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> > ---
> > 
> > Changes in v2:
> > Remove unneeded dts changes.
> > 
> >  drivers/input/keyboard/cros_ec_keyb.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> > index 6a250d6..a93d55f 100644
> > --- a/drivers/input/keyboard/cros_ec_keyb.c
> > +++ b/drivers/input/keyboard/cros_ec_keyb.c
> > @@ -286,6 +286,9 @@ static int cros_ec_keyb_work(struct notifier_block *nb,
> >  		return NOTIFY_DONE;
> >  	}
> >  
> > +	if (device_may_wakeup(ckdev->dev))
> > +		pm_wakeup_event(ckdev->dev, 0);
> > +
> >  	return NOTIFY_OK;
> >  }
> >  
> > @@ -632,6 +635,12 @@ static int cros_ec_keyb_probe(struct platform_device *pdev)
> >  		return err;
> >  	}
> >  
> > +	err = device_init_wakeup(dev, 1);
> 
> I would prefer if we did not mark cros_ec devices as wakeup sources
> unconditionally. Your original patch series was better (except it failed
> to parse the "wakeup-source" property that you introduced.

I'm curious, why is this keyboard device different than any other keyboard
device? I see several other drivers in drivers/input/keyboard/ that do an
unconditional 'device_init_wakeup(..., 1)'. Keyboards tend to be wakeup
devices...

Also, what's the idea behind sub-devices vs. the main cros-ec device reporting
wakeups? Right now, we have this in drivers/mfd/cros_ec.c:

static irqreturn_t ec_irq_thread(int irq, void *data)
{
        struct cros_ec_device *ec_dev = data;
        int ret;

        if (device_may_wakeup(ec_dev->dev))
                pm_wakeup_event(ec_dev->dev, 0);

        ret = cros_ec_get_next_event(ec_dev);
        if (ret > 0)
                blocking_notifier_call_chain(&ec_dev->event_notifier,
                                             0, ec_dev);
        return IRQ_HANDLED;
}

But now, we're going to start double-reporting wakeups? Is that
expected?

I think we have a similar overlap with the RTC driver (which is being
upstreamed now?):

https://lkml.org/lkml/2017/2/14/658
[PATCH v3 3/4] rtc: cros-ec: add cros-ec-rtc driver.

except that also goes through the trouble of enabling/disabling wakeup for the
EC IRQ. It seems to me (though I haven't dug in thoroughly) like the
main MFD shouldn't really be doing the wakeup reporting at all, and we
should depend on the sub-devices to do this. (i.e., the current patchset
is a step in the right direction, but it's not 100%.)

Anyway, I could be wrong about the above, but I think we should make
sure there's a consistent answer across the drivers tree.

Regards,
Brian

> > +	if (err) {
> > +		dev_err(dev, "cannot init wakeup: %d\n", err);
> > +		return err;
> > +	}
> > +
> >  	return 0;
> >  }
> >  
> > -- 
> > 2.1.4
> > 
> > 
> 
> Thanks.
> 
> -- 
> Dmitry

  reply	other threads:[~2017-04-03 20:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-02  0:07 [PATCH v2 0/1] Set cros_ec_keyb as a wakeup source Jeffy Chen
2017-04-02  0:07 ` [PATCH v2] input: cros_ec_keyb: Report wakeup events Jeffy Chen
2017-04-03 18:43   ` Dmitry Torokhov
2017-04-03 20:53     ` Brian Norris [this message]
2017-04-03 22:41       ` Dmitry Torokhov
2017-04-05  1:20         ` jeffy
2017-06-21  8:40           ` jeffy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170403205352.GA138246@google.com \
    --to=briannorris@chromium.org \
    --cc=dbasehore@google.com \
    --cc=dianders@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=enric.balletbo@collabora.com \
    --cc=gwendal@chromium.org \
    --cc=jeffy.chen@rock-chips.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox