Hi, Rui
> From: Zhang, Rui
> Subject: RE: [RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue by
> moving EC event handling
> earlier
>
>
> > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> > Subject: [RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue by
> >
Hi, Rui
> From: Zhang, Rui
> Subject: RE: [RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue by
> moving EC event handling
> earlier
>
>
> > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> > Subject: [RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue by
> >
Hi, David
Not a fancy way, but just a bit clearing.
OK, style is changed here:
https://github.com/acpica/acpica/pull/321
And bug is recorded here:
https://bugs.acpica.org/show_bug.cgi?id=1422
Thanks for the report.
Best regards
Lv
> From: David Binderman [mailto:dcb...@hotmail.com]
> Subject:
Hi, David
Not a fancy way, but just a bit clearing.
OK, style is changed here:
https://github.com/acpica/acpica/pull/321
And bug is recorded here:
https://bugs.acpica.org/show_bug.cgi?id=1422
Thanks for the report.
Best regards
Lv
> From: David Binderman [mailto:dcb...@hotmail.com]
> Subject:
everything is cleared to me.
Thanks and best regards
Lv
> From: Zheng, Lv
> Subject: [PATCH v4 0/3] ACPI / EC: Fix EC event handling issues
>
> EC events are special, required to be handled during suspend/resume. But
> there are special logics in Linux causing several issues related to
everything is cleared to me.
Thanks and best regards
Lv
> From: Zheng, Lv
> Subject: [PATCH v4 0/3] ACPI / EC: Fix EC event handling issues
>
> EC events are special, required to be handled during suspend/resume. But
> there are special logics in Linux causing several issues related to
Hi,
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH v3 1/4] ACPI / EC: Cleanup EC GPE mask flag
>
> On Friday, August 11, 2017 8:36:28 AM CEST Lv Zheng wrote:
> > EC_FLAGS_COMMAND_STORM is actually used to mask GPE during IRQ processing.
> > This patch cleans it up
Hi,
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH v3 1/4] ACPI / EC: Cleanup EC GPE mask flag
>
> On Friday, August 11, 2017 8:36:28 AM CEST Lv Zheng wrote:
> > EC_FLAGS_COMMAND_STORM is actually used to mask GPE during IRQ processing.
> > This patch cleans it up
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Chao Fan
> Subject: [PATCH] actbl1.h: use tab instead of seven spaces as the indentation
>
> The indentation of these two lines is seven spaces, but not tab.
> So fix it.
>
> Signed-off-by:
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Chao Fan
> Subject: [PATCH] actbl1.h: use tab instead of seven spaces as the indentation
>
> The indentation of these two lines is seven spaces, but not tab.
> So fix it.
>
> Signed-off-by:
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the
> namespace
>
> On Tuesday, August 15, 2017 4:12:24 AM CEST Zheng, Lv wrote:
> > Hi, Rafael
> >
> > > Fr
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the
> namespace
>
> On Tuesday, August 15, 2017 4:12:24 AM CEST Zheng, Lv wrote:
> > Hi, Rafael
> >
> > > Fr
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time
>
> On Tuesday, August 15, 2017 11:59:00 AM CEST Zheng, Lv wrote:
> > Hi,
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time
>
> On Tuesday, August 15, 2017 11:59:00 AM CEST Zheng, Lv wrote:
> > Hi,
Hi,
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time
>
> On Friday, August 11, 2017 7:40:56 AM CEST Zheng, Lv wrote:
> > Hi, Rafael
> >
> > > From: Rafael J. Wysocki [mailto:r...@rjwysocki
Hi,
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time
>
> On Friday, August 11, 2017 7:40:56 AM CEST Zheng, Lv wrote:
> > Hi, Rafael
> >
> > > From: Rafael J. Wysocki [mailto:r...@rjwysocki
Hi, Rafael
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the namespace
>
> From: Rafael J. Wysocki
>
> On some systems the
Hi, Rafael
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the namespace
>
> From: Rafael J. Wysocki
>
> On some systems the platform firmware expects GPEs to
Hi,
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs
> earlier
>
> On Thursday, August 10, 2017 3:52:05 AM CEST Zheng, Lv wrote:
> > Hi, Rafael
> >
> > For this patch, I have a
Hi,
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs
> earlier
>
> On Thursday, August 10, 2017 3:52:05 AM CEST Zheng, Lv wrote:
> > Hi, Rafael
> >
> > For this patch, I have a
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time
>
> On Thursday, August 10, 2017 3:48:58 AM CEST Zheng, Lv wrote:
> > Hi, Rafael
> >
> > > From: Rafael J. Wysocki [mailto:
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time
>
> On Thursday, August 10, 2017 3:48:58 AM CEST Zheng, Lv wrote:
> > Hi, Rafael
> >
> > > From: Rafael J. Wysocki [mailto:
Hi,
> From: Lukas Wunner [mailto:lu...@wunner.de]
> Subject: Re: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the
> namespace
>
> On Thu, Aug 10, 2017 at 12:34:23AM +0200, Rafael J. Wysocki wrote:
> > --- linux-pm.orig/drivers/acpi/scan.c
> > +++ linux-pm/drivers/acpi/scan.c
> > @@
Hi,
> From: Lukas Wunner [mailto:lu...@wunner.de]
> Subject: Re: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the
> namespace
>
> On Thu, Aug 10, 2017 at 12:34:23AM +0200, Rafael J. Wysocki wrote:
> > --- linux-pm.orig/drivers/acpi/scan.c
> > +++ linux-pm/drivers/acpi/scan.c
> > @@
Hi, Rafael
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the namespace
>
> From: Rafael J. Wysocki
>
> On some systems the
Hi, Rafael
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the namespace
>
> From: Rafael J. Wysocki
>
> On some systems the platform firmware expects GPEs to
Hi, Rafael
For this patch, I have a concern.
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier
>
> From: Rafael J. Wysocki
>
> Runtime GPEs have corresponding _Lxx/_Exx methods and
Hi, Rafael
For this patch, I have a concern.
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier
>
> From: Rafael J. Wysocki
>
> Runtime GPEs have corresponding _Lxx/_Exx methods and are enabled
> automatically
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time
>
> From: Rafael J. Wysocki
>
> In some cases GPEs are already active when they are enabled by
> acpi_ev_initialize_gpe_block() and
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time
>
> From: Rafael J. Wysocki
>
> In some cases GPEs are already active when they are enabled by
> acpi_ev_initialize_gpe_block() and whatever happens next may depend
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Song
> liwei
> Subject: [PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware
> bug
>
> From: Liwei Song
>
> This is a follow up to commit
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Song
> liwei
> Subject: [PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware
> bug
>
> From: Liwei Song
>
> This is a follow up to commit f712c71f7b2b ("ACPI, APEI: Fixup
7/18/17 at 02:08pm, Dou Liyang wrote:
> >> Hi, Zheng
> >>
> >> At 07/18/2017 01:18 PM, Zheng, Lv wrote:
> >>> Hi,
> >>>
> >>> Can the problem be fixed by invoking acpi_put_table() for mapped DMAR
> >>> table?
> >>
&
7/18/17 at 02:08pm, Dou Liyang wrote:
> >> Hi, Zheng
> >>
> >> At 07/18/2017 01:18 PM, Zheng, Lv wrote:
> >>> Hi,
> >>>
> >>> Can the problem be fixed by invoking acpi_put_table() for mapped DMAR
> >>> table?
> >>
&
..@zytor.com;
> ebied...@xmission.com; b...@redhat.com;
> pet...@infradead.org; izumi.t...@jp.fujitsu.com;
> tokunaga.kei...@jp.fujitsu.com; Dou Liyang
> <douly.f...@cn.fujitsu.com>; linux-a...@vger.kernel.org; Rafael J. Wysocki
> <r...@rjwysocki.net>; Zheng,
> Lv <
..@zytor.com;
> ebied...@xmission.com; b...@redhat.com;
> pet...@infradead.org; izumi.t...@jp.fujitsu.com;
> tokunaga.kei...@jp.fujitsu.com; Dou Liyang
> ; linux-a...@vger.kernel.org; Rafael J. Wysocki
> ; Zheng,
> Lv ; Julian Wollrath
> Subject: [PATCH v7 12/13] ACPI / init:
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH 3/3] ACPI: EC: Change EC noirq tuning to be an optional
> behavior
>
> On Wednesday, June 14, 2017 01:59:24 PM Lv Zheng wrote:
> > According to the bug report, though the busy polling mode can make noirq
> >
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH 3/3] ACPI: EC: Change EC noirq tuning to be an optional
> behavior
>
> On Wednesday, June 14, 2017 01:59:24 PM Lv Zheng wrote:
> > According to the bug report, though the busy polling mode can make noirq
> >
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: [PATCH] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent
> systems
>
> From: Rafael J. Wysocki
>
> Some recent Dell laptops, including the XPS13 model numbers 9360 and
> 9365,
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: [PATCH] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent
> systems
>
> From: Rafael J. Wysocki
>
> Some recent Dell laptops, including the XPS13 model numbers 9360 and
> 9365, cannot be woken up from
Hi,
> From: Bastien Nocera [mailto:had...@hadess.net]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Tue, 2017-06-20 at 02:45 +, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Bastien Nocera [mailto:
Hi,
> From: Bastien Nocera [mailto:had...@hadess.net]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Tue, 2017-06-20 at 02:45 +, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Bastien Nocera [mailto:
Hi, Rafael
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from
> suspend-to-idle on recent Dell systems
>
> On Tue, Jun 20, 2017 at 2:07 AM, Linus Torvalds
>
Hi, Rafael
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from
> suspend-to-idle on recent Dell systems
>
> On Tue, Jun 20, 2017 at 2:07 AM, Linus Torvalds
>
Hi,
> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from
> suspend-to-idle on recent Dell systems
>
> On Tue, Jun 20, 2017 at 1:37 AM, Zheng, Lv <lv.zh...@intel.com&g
Hi,
> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from
> suspend-to-idle on recent Dell systems
>
> On Tue, Jun 20, 2017 at 1:37 AM, Zheng, Lv wrote:
> > Hi, Raf
Hi,
> From: Bastien Nocera [mailto:had...@hadess.net]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Mon, 2017-06-19 at 01:43 +, Zheng, Lv wrote:
> >
> > >
> > > If you implement it i
Hi,
> From: Bastien Nocera [mailto:had...@hadess.net]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Mon, 2017-06-19 at 01:43 +, Zheng, Lv wrote:
> >
> > >
> > > If you implement it i
Hi, Rafael
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on
> recent Dell systems
>
> From: Rafael J. Wysocki
>
>
Hi, Rafael
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on
> recent Dell systems
>
> From: Rafael J. Wysocki
>
> Some recent Dell laptops,
Hi, Lennart
> From: Lennart Poettering [mailto:mzxre...@0pointer.de]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Fri, 16.06.17 11:06, Bastien Nocera (had...@hadess.net) wrote:
>
> > > Let's consider this case with delay:
> > > After
Hi, Lennart
> From: Lennart Poettering [mailto:mzxre...@0pointer.de]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Fri, 16.06.17 11:06, Bastien Nocera (had...@hadess.net) wrote:
>
> > > Let's consider this case with delay:
> > > After
Hi,
> From: Bastien Nocera [mailto:had...@hadess.net]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
>
>
> > On 16 Jun 2017, at 10:53, Zheng, Lv <lv.zh...@intel.com> wrote:
> >
>
Hi,
> From: Bastien Nocera [mailto:had...@hadess.net]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
>
>
> > On 16 Jun 2017, at 10:53, Zheng, Lv wrote:
> >
> > Hi,
> >
> >> From: Benja
Hi,
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Jun 16 2017 or thereabouts, Zheng, Lv wrote:
> > Hi, Benjamin
> >
> > Let me
Hi,
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Jun 16 2017 or thereabouts, Zheng, Lv wrote:
> > Hi, Benjamin
> >
> > Let me
Hi, Benjamin
Let me just say something one more time.
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Jun 16 2017 or thereabouts, Zheng, Lv wrote:
> &g
Hi, Benjamin
Let me just say something one more time.
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Jun 16 2017 or thereabouts, Zheng, Lv wrote:
> &g
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Peter
> Hutterer
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Thu, Jun 15, 2017 at 07:33:58AM +, Zheng, Lv
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Peter
> Hutterer
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Thu, Jun 15, 2017 at 07:33:58AM +, Zheng, Lv
Hi, Peter
> From: Peter Hutterer [mailto:peter.hutte...@who-t.net]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Thu, Jun 15, 2017 at 02:52:57AM +, Zheng, Lv wrote:
> > Hi, Benjamin
> >
>
Hi, Peter
> From: Peter Hutterer [mailto:peter.hutte...@who-t.net]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Thu, Jun 15, 2017 at 02:52:57AM +, Zheng, Lv wrote:
> > Hi, Benjamin
> >
>
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> Hi,
>
> [Sorry for the delay, I have been sidetracked from this]
>
> On Jun 07 2017 or thereabouts, Lennart
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> Hi,
>
> [Sorry for the delay, I have been sidetracked from this]
>
> On Jun 07 2017 or thereabouts, Lennart
Hi,
> From: Lennart Poettering [mailto:mzxre...@0pointer.de]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Thu, 01.06.17 20:46, Benjamin Tissoires (benjamin.tissoi...@redhat.com)
> wrote:
>
> > Hi,
> >
> > Sending this as a WIP as it
Hi,
> From: Lennart Poettering [mailto:mzxre...@0pointer.de]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
> exported by ACPI
>
> On Thu, 01.06.17 20:46, Benjamin Tissoires (benjamin.tissoi...@redhat.com)
> wrote:
>
> > Hi,
> >
> > Sending this as a WIP as it
Hi,
> From: Seraphime Kirkovski
>
> On Wed, Jun 07, 2017 at 03:14:46PM +, Moore, Robert wrote:
> > I believe that the rationale for this is that at that point in the code, it
> > is *guaranteed* that
> there is at least one operand; therefore the -1 would always be valid.
> >
> > In the
Hi,
> From: Seraphime Kirkovski
>
> On Wed, Jun 07, 2017 at 03:14:46PM +, Moore, Robert wrote:
> > I believe that the rationale for this is that at that point in the code, it
> > is *guaranteed* that
> there is at least one operand; therefore the -1 would always be valid.
> >
> > In the
Hi, Dan
> From: Dan Williams [mailto:dan.j.willi...@intel.com]
> Subject: Re: [PATCH v5] ACPICA: Tables: Add mechanism to allow to balance
> late stage acpi_get_table()
> independently
>
> On Wed, Jun 7, 2017 at 2:14 PM, Rafael J. Wysocki wrote:
> > On Wed, Jun 7, 2017 at
Hi, Dan
> From: Dan Williams [mailto:dan.j.willi...@intel.com]
> Subject: Re: [PATCH v5] ACPICA: Tables: Add mechanism to allow to balance
> late stage acpi_get_table()
> independently
>
> On Wed, Jun 7, 2017 at 2:14 PM, Rafael J. Wysocki wrote:
> > On Wed, Jun 7, 2017 at 8:41 AM, Dan Williams
Hi, Benjamin
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Benjamin
> Tissoires
> Subject: Re: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the
> state is unknown
>
> Hi Lv,
>
> On Jun 05 2017 or t
Hi, Benjamin
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Benjamin
> Tissoires
> Subject: Re: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the
> state is unknown
>
> Hi Lv,
>
> On Jun 05 2017 or t
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks
>
> On Jun 05 2017 or thereabouts, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Benjamin Tissoires [mai
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks
>
> On Jun 05 2017 or thereabouts, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Benjamin Tissoires [mai
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: [WIP PATCH 3/4] ACPI: button: Let input filter out the LID events
>
> The input stack already filters out the LID events. So instead of
> filtering them out at the source, we can hook up after the input
>
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: [WIP PATCH 3/4] ACPI: button: Let input filter out the LID events
>
> The input stack already filters out the LID events. So instead of
> filtering them out at the source, we can hook up after the input
>
Hi,
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks
>
> From: Lv Zheng
>
> acpi/button.c now contains the logic to avoid frequently replayed events
> which originally was ensured by using
Hi,
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks
>
> From: Lv Zheng
>
> acpi/button.c now contains the logic to avoid frequently replayed events
> which originally was ensured by using blocking notifier.
>
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the
> state is unknown
>
> Because of the variation of firmware implementation, there is a chance
> the LID state is unknown:
> 1. Some
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the
> state is unknown
>
> Because of the variation of firmware implementation, there is a chance
> the LID state is unknown:
> 1. Some
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI
>
> Hi,
>
> Sending this as a WIP as it still need a few changes, but it mostly works as
> expected (still not fully compliant yet).
>
>
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI
>
> Hi,
>
> Sending this as a WIP as it still need a few changes, but it mostly works as
> expected (still not fully compliant yet).
>
>
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: [GIT PULL] ACPI fixes for v4.12-rc4
>
> Hi Linus,
>
> Please pull from the tag
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
>
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: [GIT PULL] ACPI fixes for v4.12-rc4
>
> Hi Linus,
>
> Please pull from the tag
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
>
Hi,
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [RFC PATCH v3 5/5] ACPI: button: Always notify kernel space
> using _LID returning value
>
> Hi Lv,
>
> On May 27 2017 or thereabouts, Lv Zheng wrote:
> > Both nouveau and i915, the only 2 kernel space lid
Hi,
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [RFC PATCH v3 5/5] ACPI: button: Always notify kernel space
> using _LID returning value
>
> Hi Lv,
>
> On May 27 2017 or thereabouts, Lv Zheng wrote:
> > Both nouveau and i915, the only 2 kernel space lid
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Benjamin
> Tissoires
> Subject: Re: [RFC PATCH v3 1/5] ACPI: button: Add indication of BIOS
> notification and faked events
>
> Hi Lv,
>
> On May 27 2017 or thereabouts, Lv Zheng wrote:
> >
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Benjamin
> Tissoires
> Subject: Re: [RFC PATCH v3 1/5] ACPI: button: Add indication of BIOS
> notification and faked events
>
> Hi Lv,
>
> On May 27 2017 or thereabouts, Lv Zheng wrote:
> >
Hi,
> >> >> >> Benjamin, my understanding is that this is the case, is it correct?
> >> >> >
> >> >> > That is correct. This patch I reverted introduces regression for
> >> >> > professional
> >> >> > laptops that expect the LID switch to be reported accurately.
> >> >>
> >> >> And from a user's
Hi,
> >> >> >> Benjamin, my understanding is that this is the case, is it correct?
> >> >> >
> >> >> > That is correct. This patch I reverted introduces regression for
> >> >> > professional
> >> >> > laptops that expect the LID switch to be reported accurately.
> >> >>
> >> >> And from a user's
Hi, Benjamin
> > What's that?
> > I mean, the bad faith?
> I already explained 4 times why we need to revert these two patches and
> why we need to keep 'method'. And you keep answering with long emails
> that you would rather not. I call it bad faith, sorry.
The 4 times explanations didn't
Hi, Benjamin
> > What's that?
> > I mean, the bad faith?
> I already explained 4 times why we need to revert these two patches and
> why we need to keep 'method'. And you keep answering with long emails
> that you would rather not. I call it bad faith, sorry.
The 4 times explanations didn't
Hi, Benjamin
> > > > > >> >> > > > > For example, such a hwdb entry is:
> > > > > >> >> > > > > libinput:name:*Lid
> > > > > >> >> > > > > Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:*
> > > > > >> >> > > > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open
> > > > > >> >> Well, if it worked
Hi, Benjamin
> > > > > >> >> > > > > For example, such a hwdb entry is:
> > > > > >> >> > > > > libinput:name:*Lid
> > > > > >> >> > > > > Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:*
> > > > > >> >> > > > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open
> > > > > >> >> Well, if it worked
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng,
> Lv
> Subject: RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to
> lid_init_state=open"
>
> Hi, Guys
>
> > From: Be
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng,
> Lv
> Subject: RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to
> lid_init_state=open"
>
> Hi, Guys
>
> > From: Be
>> > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote:
> > >> >> On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > > From: Be
at 11:37 AM, Benjamin Tissoires
> > wrote:
> > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote:
> > >> On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires
> > >> wrote:
> > >> > On May 12 2017 or thereabouts, Rafael J. Wysocki
Hi, Benjamin
I reordered the discussion to collect topics and delete things to make
discussion shorter.
1. root caused issue:
> > It seems we just need to determine the following first:
> > 1. Who should be responsible for solving bugs triggered by the conflict
> > between bios and linux user
Hi, Benjamin
I reordered the discussion to collect topics and delete things to make
discussion shorter.
1. root caused issue:
> > It seems we just need to determine the following first:
> > 1. Who should be responsible for solving bugs triggered by the conflict
> > between bios and linux user
1 - 100 of 918 matches
Mail list logo