2017-06-27 16:24:17

by Benson Leung

[permalink] [raw]
Subject: Re: [PATCH v2 3/3] cros_ec: Don't signal wake event for non-wake host events

Hi Thierry,

On Tue, Feb 14, 2017 at 08:58:02PM +0100, Thierry Escande wrote:
> From: Shawn Nematbakhsh <[email protected]>
>
> The subset of wake-enabled host events is defined by the EC, but the EC
> may still send non-wake host events if we're in the process of
> suspending. Get the mask of wake-enabled host events from the EC and
> filter out non-wake events to prevent spurious aborted suspend
> attempts.
>
> Signed-off-by: Shawn Nematbakhsh <[email protected]>
> Signed-off-by: Thierry Escande <[email protected]>
> ---
> drivers/mfd/cros_ec.c | 13 ++++--
> drivers/platform/chrome/cros_ec_proto.c | 76 ++++++++++++++++++++++++++++++---
> include/linux/mfd/cros_ec.h | 5 ++-
> 3 files changed, 85 insertions(+), 9 deletions(-)
>

Another use of cros_ec_get_next_event was introduced in cros_ec_lpc.c since
this patch was posted, so I went ahead and modified that too.

Applied. Thanks.


--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
[email protected]
Chromium OS Project
[email protected]


Attachments:
(No filename) (1.05 kB)
signature.asc (819.00 B)
Digital signature
Download all attachments

2017-07-03 11:46:47

by Lee Jones

[permalink] [raw]
Subject: Re: [PATCH v2 3/3] cros_ec: Don't signal wake event for non-wake host events

On Tue, 27 Jun 2017, Benson Leung wrote:

> Hi Thierry,
>
> On Tue, Feb 14, 2017 at 08:58:02PM +0100, Thierry Escande wrote:
> > From: Shawn Nematbakhsh <[email protected]>
> >
> > The subset of wake-enabled host events is defined by the EC, but the EC
> > may still send non-wake host events if we're in the process of
> > suspending. Get the mask of wake-enabled host events from the EC and
> > filter out non-wake events to prevent spurious aborted suspend
> > attempts.
> >
> > Signed-off-by: Shawn Nematbakhsh <[email protected]>
> > Signed-off-by: Thierry Escande <[email protected]>
> > ---
> > drivers/mfd/cros_ec.c | 13 ++++--
> > drivers/platform/chrome/cros_ec_proto.c | 76 ++++++++++++++++++++++++++++++---
> > include/linux/mfd/cros_ec.h | 5 ++-
> > 3 files changed, 85 insertions(+), 9 deletions(-)
> >
>
> Another use of cros_ec_get_next_event was introduced in cros_ec_lpc.c since
> this patch was posted, so I went ahead and modified that too.
>
> Applied. Thanks.

No need to change anything this time, but please note the "for my own
reference" in my Ack in future. It typically means that I plan on
pushing it through the MFD tree or that it requires further discussion
(in the case that another Maintainer would prefer it go through their
tree).

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

2017-07-05 20:11:21

by Benson Leung

[permalink] [raw]
Subject: Re: [PATCH v2 3/3] cros_ec: Don't signal wake event for non-wake host events

Hi Lee,

On Mon, Jul 03, 2017 at 12:46:41PM +0100, Lee Jones wrote:
> On Tue, 27 Jun 2017, Benson Leung wrote:
>
> > Hi Thierry,
> >
> > On Tue, Feb 14, 2017 at 08:58:02PM +0100, Thierry Escande wrote:
> > > From: Shawn Nematbakhsh <[email protected]>
> > >
> > > The subset of wake-enabled host events is defined by the EC, but the EC
> > > may still send non-wake host events if we're in the process of
> > > suspending. Get the mask of wake-enabled host events from the EC and
> > > filter out non-wake events to prevent spurious aborted suspend
> > > attempts.
> > >
> > > Signed-off-by: Shawn Nematbakhsh <[email protected]>
> > > Signed-off-by: Thierry Escande <[email protected]>
> > > ---
> > > drivers/mfd/cros_ec.c | 13 ++++--
> > > drivers/platform/chrome/cros_ec_proto.c | 76 ++++++++++++++++++++++++++++++---
> > > include/linux/mfd/cros_ec.h | 5 ++-
> > > 3 files changed, 85 insertions(+), 9 deletions(-)
> > >
> >
> > Another use of cros_ec_get_next_event was introduced in cros_ec_lpc.c since
> > this patch was posted, so I went ahead and modified that too.
> >
> > Applied. Thanks.
>
> No need to change anything this time, but please note the "for my own
> reference" in my Ack in future. It typically means that I plan on
> pushing it through the MFD tree or that it requires further discussion
> (in the case that another Maintainer would prefer it go through their
> tree).
>

Sorry about that. Thanks for the advice! I'm still getting my sea legs for
maintainership.

Benson

--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
[email protected]
Chromium OS Project
[email protected]


Attachments:
(No filename) (1.65 kB)
signature.asc (819.00 B)
Digital signature
Download all attachments

2017-07-06 07:12:42

by Lee Jones

[permalink] [raw]
Subject: Re: [PATCH v2 3/3] cros_ec: Don't signal wake event for non-wake host events

On Wed, 05 Jul 2017, Benson Leung wrote:
> On Mon, Jul 03, 2017 at 12:46:41PM +0100, Lee Jones wrote:
> > On Tue, 27 Jun 2017, Benson Leung wrote:
> >
> > > Hi Thierry,
> > >
> > > On Tue, Feb 14, 2017 at 08:58:02PM +0100, Thierry Escande wrote:
> > > > From: Shawn Nematbakhsh <[email protected]>
> > > >
> > > > The subset of wake-enabled host events is defined by the EC, but the EC
> > > > may still send non-wake host events if we're in the process of
> > > > suspending. Get the mask of wake-enabled host events from the EC and
> > > > filter out non-wake events to prevent spurious aborted suspend
> > > > attempts.
> > > >
> > > > Signed-off-by: Shawn Nematbakhsh <[email protected]>
> > > > Signed-off-by: Thierry Escande <[email protected]>
> > > > ---
> > > > drivers/mfd/cros_ec.c | 13 ++++--
> > > > drivers/platform/chrome/cros_ec_proto.c | 76 ++++++++++++++++++++++++++++++---
> > > > include/linux/mfd/cros_ec.h | 5 ++-
> > > > 3 files changed, 85 insertions(+), 9 deletions(-)
> > > >
> > >
> > > Another use of cros_ec_get_next_event was introduced in cros_ec_lpc.c since
> > > this patch was posted, so I went ahead and modified that too.
> > >
> > > Applied. Thanks.
> >
> > No need to change anything this time, but please note the "for my own
> > reference" in my Ack in future. It typically means that I plan on
> > pushing it through the MFD tree or that it requires further discussion
> > (in the case that another Maintainer would prefer it go through their
> > tree).
>
> Sorry about that. Thanks for the advice! I'm still getting my sea legs for
> maintainership.

It's not your fault. The tag I use is non-standard, so I expect some
trivial issues like this to occur from time to time. But it solves
more problems than it creates, so it's still work me using it.

Thanks for your understanding.

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog