RE: [RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue by moving EC event handling earlier

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 > >

RE: [RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue by moving EC event handling earlier

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 > >

RE: linux-4.14-rc2/drivers/acpi/acpica/utmath.c: 2 * suspicious expression ?

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:

RE: linux-4.14-rc2/drivers/acpi/acpica/utmath.c: 2 * suspicious expression ?

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:

RE: [PATCH v4 0/3] ACPI / EC: Fix EC event handling issues

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

RE: [PATCH v4 0/3] ACPI / EC: Fix EC event handling issues

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

RE: [PATCH v3 1/4] ACPI / EC: Cleanup EC GPE mask flag

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

RE: [PATCH v3 1/4] ACPI / EC: Cleanup EC GPE mask flag

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

RE: [PATCH] actbl1.h: use tab instead of seven spaces as the indentation

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:

RE: [PATCH] actbl1.h: use tab instead of seven spaces as the indentation

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:

RE: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the namespace

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

RE: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the namespace

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

RE: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time

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,

RE: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time

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,

RE: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time

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

RE: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time

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

RE: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the namespace

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

RE: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the namespace

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

RE: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier

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

RE: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier

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

RE: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time

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:

RE: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time

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:

RE: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the namespace

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 > > @@

RE: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the namespace

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 > > @@

RE: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the namespace

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

RE: [PATCH 3/3] ACPI / scan: Enable GPEs before scanning the namespace

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

RE: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier

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

RE: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier

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

RE: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time

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

RE: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time

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

RE: [PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug

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

RE: [PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug

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

RE: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

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? > >> &

RE: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

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? > >> &

RE: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

..@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 <

RE: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

..@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:

RE: [PATCH 3/3] ACPI: EC: Change EC noirq tuning to be an optional behavior

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 > >

RE: [PATCH 3/3] ACPI: EC: Change EC noirq tuning to be an optional behavior

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 > >

RE: [PATCH] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

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,

RE: [PATCH] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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:

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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:

RE: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent Dell systems

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 >

RE: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent Dell systems

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 >

RE: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent Dell systems

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

RE: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent Dell systems

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent Dell systems

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 > >

RE: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent Dell systems

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,

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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: > > >

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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 > > >

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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 > > >

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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

RE: [PATCH] acpi: acpica: dsutils: fixanoff-by-one index

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

RE: [PATCH] acpi: acpica: dsutils: fixanoff-by-one index

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

RE: [PATCH v5] ACPICA: Tables: Add mechanism to allow to balance late stage acpi_get_table() independently

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

RE: [PATCH v5] ACPICA: Tables: Add mechanism to allow to balance late stage acpi_get_table() independently

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

RE: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the state is unknown

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

RE: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the state is unknown

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

RE: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks

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

RE: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks

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

RE: [WIP PATCH 3/4] ACPI: button: Let input filter out the LID events

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 >

RE: [WIP PATCH 3/4] ACPI: button: Let input filter out the LID events

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 >

RE: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks

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

RE: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks

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. >

RE: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the state is unknown

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

RE: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the state is unknown

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

RE: [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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). > >

RE: [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

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). > >

RE: [GIT PULL] ACPI fixes for v4.12-rc4

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 \ >

RE: [GIT PULL] ACPI fixes for v4.12-rc4

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 \ >

RE: [RFC PATCH v3 5/5] ACPI: button: Always notify kernel space using _LID returning value

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

RE: [RFC PATCH v3 5/5] ACPI: button: Always notify kernel space using _LID returning value

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

RE: [RFC PATCH v3 1/5] ACPI: button: Add indication of BIOS notification and faked events

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: > >

RE: [RFC PATCH v3 1/5] ACPI: button: Add indication of BIOS notification and faked events

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: > >

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

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

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

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

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

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

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

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

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

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

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

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

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

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

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

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

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

>> > 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

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

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

RE: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

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

RE: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

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   2   3   4   5   6   7   8   9   10   >