From: Brian Norris <briannorris@chromium.org>
To: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Cc: dmitry.torokhov@gmail.com, lee.jones@linaro.org,
ravisadineni@google.com, dtor@google.com, tbroch@google.com,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
rajatja@google.com, bleung@google.com
Subject: Re: [PATCH V2] cros_ec_keyb: Mark cros_ec_keyb driver as wake enabled device.
Date: Mon, 4 Jun 2018 18:32:52 -0700 [thread overview]
Message-ID: <20180605013250.GA41281@rodete-desktop-imager.corp.google.com> (raw)
In-Reply-To: <20180526011440.102417-1-ravisadineni@chromium.org>
Hi,
On Fri, May 25, 2018 at 06:14:40PM -0700, Ravi Chandra Sadineni wrote:
> Mark cros_ec_keyb has wake enabled by default. If we see a MKBP event
> related to keyboard, call pm_wakeup_event() to make sure wakeup
> triggers are accounted to keyb during suspend resume path.
>
> Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
> ---
> V2: Marked the ckdev as wake enabled instead of input devices.
I'm not sure I saw v1? But FYI, if you're not marking the input devices
as wake-enabled, then you only have one knob for disabling wakeup on the
buttons and switches (e.g., power button) vs. the keyboard. I know you
were previously concerned about this, but given that the EC itself
usually has full knowledge of these situations (e.g., it knows to
disable keyboard wakeup when a convertible is in a tablet orientation,
but leave power-button wakeup enabled), this may not be a problem.
Anyway, just wanted to highlight that part.
> drivers/input/keyboard/cros_ec_keyb.c | 21 +++++++++++++++++----
> drivers/mfd/cros_ec.c | 19 +++++++------------
> 2 files changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> index 79eb29550c348..a7c96f0317123 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -245,12 +245,17 @@ static int cros_ec_keyb_work(struct notifier_block *nb,
> switch (ckdev->ec->event_data.event_type) {
> case EC_MKBP_EVENT_KEY_MATRIX:
> /*
> - * If EC is not the wake source, discard key state changes
> + * If Keyb is not wake enabled, discard key state changes
We can use the full word; text is cheap:
s/Keyb/keyboard/
> * during suspend.
> */
> - if (queued_during_suspend)
> + if (queued_during_suspend
> + && !device_may_wakeup(ckdev->dev))
> return NOTIFY_OK;
>
> + if (device_may_wakeup(ckdev->dev))
> + pm_wakeup_event(ckdev->dev, 0);
> +
> +
I don't think you need two blank lines here. One is enough.
> if (ckdev->ec->event_size != ckdev->cols) {
> dev_err(ckdev->dev,
> "Discarded incomplete key matrix event.\n");
> @@ -265,18 +270,25 @@ static int cros_ec_keyb_work(struct notifier_block *nb,
> val = get_unaligned_le32(&ckdev->ec->event_data.data.sysrq);
> dev_dbg(ckdev->dev, "sysrq code from EC: %#x\n", val);
> handle_sysrq(val);
> +
> + if (device_may_wakeup(ckdev->dev))
> + pm_wakeup_event(ckdev->dev, 0);
> break;
>
> case EC_MKBP_EVENT_BUTTON:
> case EC_MKBP_EVENT_SWITCH:
> /*
> - * If EC is not the wake source, discard key state
> + * If keyb is not wake enabled, discard key state
s/keyb/keyboard/
Or, since this is talking about buttons and switches (which don't
technically require the "keyboard" part of this driver), you might just
leave that off ("If not wake enabled...").
Otherwise, I believe this looks good, though I may have overlooked
something:
Reviewed-by: Brian Norris <briannorris@chromium.org>
And given Lee acked this, and it's mostly a keyboard change, it should
probably go through Dmitry? And I'd expect he'd be a better reviewer
than me anyway.
Brian
> * changes during suspend. Switches will be re-checked in
> * cros_ec_keyb_resume() to be sure nothing is lost.
> */
> - if (queued_during_suspend)
> + if (queued_during_suspend
> + && !device_may_wakeup(ckdev->dev))
> return NOTIFY_OK;
>
> + if (device_may_wakeup(ckdev->dev))
> + pm_wakeup_event(ckdev->dev, 0);
> +
> if (ckdev->ec->event_data.event_type == EC_MKBP_EVENT_BUTTON) {
> val = get_unaligned_le32(
> &ckdev->ec->event_data.data.buttons);
> @@ -639,6 +651,7 @@ static int cros_ec_keyb_probe(struct platform_device *pdev)
> return err;
> }
>
> + device_init_wakeup(ckdev->dev, true);
> return 0;
> }
>
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index d61024141e2b6..36156a41499c9 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -229,7 +229,7 @@ int cros_ec_suspend(struct cros_ec_device *ec_dev)
> }
> EXPORT_SYMBOL(cros_ec_suspend);
>
> -static void cros_ec_drain_events(struct cros_ec_device *ec_dev)
> +static void cros_ec_report_events_during_suspend(struct cros_ec_device *ec_dev)
> {
> while (cros_ec_get_next_event(ec_dev, NULL) > 0)
> blocking_notifier_call_chain(&ec_dev->event_notifier,
> @@ -253,21 +253,16 @@ int cros_ec_resume(struct cros_ec_device *ec_dev)
> dev_dbg(ec_dev->dev, "Error %d sending resume event to ec",
> ret);
>
> - /*
> - * In some cases, we need to distinguish between events that occur
> - * during suspend if the EC is not a wake source. For example,
> - * keypresses during suspend should be discarded if it does not wake
> - * the system.
> - *
> - * If the EC is not a wake source, drain the event queue and mark them
> - * as "queued during suspend".
> - */
> if (ec_dev->wake_enabled) {
> disable_irq_wake(ec_dev->irq);
> ec_dev->wake_enabled = 0;
> - } else {
> - cros_ec_drain_events(ec_dev);
> }
> + /*
> + * Let the mfd devices know about events that occur during
> + * suspend. This way the clients know what to do with them.
> + */
> + cros_ec_report_events_during_suspend(ec_dev);
> +
>
> return 0;
> }
> --
> 2.17.0.921.gf22659ad46-goog
>
prev parent reply other threads:[~2018-06-05 1:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 18:29 [PATCH] cros_ec_keyb: Increment the wakeup count to the specific mfd device Ravi Chandra Sadineni
2018-05-24 23:42 ` Dmitry Torokhov
2018-05-26 1:14 ` [PATCH V2] cros_ec_keyb: Mark cros_ec_keyb driver as wake enabled device Ravi Chandra Sadineni
2018-06-04 6:18 ` Lee Jones
2018-06-05 1:32 ` Brian Norris [this message]
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=20180605013250.GA41281@rodete-desktop-imager.corp.google.com \
--to=briannorris@chromium.org \
--cc=bleung@google.com \
--cc=dmitry.torokhov@gmail.com \
--cc=dtor@google.com \
--cc=lee.jones@linaro.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rajatja@google.com \
--cc=ravisadineni@chromium.org \
--cc=ravisadineni@google.com \
--cc=tbroch@google.com \
/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
all inboxes | Powered by JetHome®