All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.