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

2017-11-23 Thread Zheng, Lv
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 ?

2017-09-27 Thread Zheng, Lv
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

2017-09-26 Thread Zheng, Lv
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

2017-08-22 Thread Zheng, Lv
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

2017-08-22 Thread Zheng, Lv
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

2017-08-16 Thread Zheng, Lv
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

2017-08-16 Thread Zheng, Lv
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

2017-08-15 Thread Zheng, Lv
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

2017-08-14 Thread Zheng, Lv
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 2/3] ACPICA: Make it possible to enable runtime GPEs earlier

2017-08-11 Thread Zheng, Lv
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

2017-08-10 Thread Zheng, Lv
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

2017-08-10 Thread Zheng, Lv
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

2017-08-09 Thread Zheng, Lv
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 2/3] ACPICA: Make it possible to enable runtime GPEs earlier

2017-08-09 Thread Zheng, Lv
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 1/3] ACPICA: Dispatch active GPEs at init time

2017-08-09 Thread Zheng, Lv
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 V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug

2017-07-30 Thread Zheng, Lv
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 v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

2017-07-27 Thread Zheng, Lv
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

2017-07-17 Thread 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 > <douly.f...@cn.fujitsu.com>; linux-a...@vger.kernel.org; Rafael J. Wysocki > <r...@rjwysocki.net>; Zheng, > Lv <

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

2017-07-02 Thread Zheng, Lv
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

2017-06-23 Thread Zheng, Lv
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: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

2017-06-21 Thread Zheng, Lv
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

2017-06-20 Thread Zheng, Lv
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

2017-06-20 Thread Zheng, Lv
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: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

2017-06-19 Thread Zheng, Lv
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

2017-06-19 Thread Zheng, Lv
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: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

2017-06-18 Thread Zheng, Lv
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

2017-06-18 Thread Zheng, Lv
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

2017-06-16 Thread Zheng, Lv
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

2017-06-16 Thread Zheng, Lv
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

2017-06-15 Thread 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

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

2017-06-15 Thread 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 > > >

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

2017-06-14 Thread Zheng, Lv
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

2017-06-14 Thread Zheng, Lv
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

2017-06-08 Thread Zheng, Lv
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

2017-06-07 Thread Zheng, Lv
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: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the state is unknown

2017-06-07 Thread Zheng, Lv
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

2017-06-07 Thread Zheng, Lv
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

2017-06-04 Thread Zheng, Lv
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

2017-06-04 Thread Zheng, Lv
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 2/4] ACPI: button: remove the LID input node when the state is unknown

2017-06-04 Thread Zheng, Lv
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

2017-06-04 Thread Zheng, Lv
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

2017-06-04 Thread Zheng, Lv
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

2017-05-31 Thread Zheng, Lv
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

2017-05-31 Thread Zheng, Lv
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"

2017-05-25 Thread Zheng, Lv
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"

2017-05-17 Thread Zheng, Lv
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"

2017-05-16 Thread Zheng, Lv
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"

2017-05-15 Thread Zheng, Lv
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"

2017-05-15 Thread Zheng, Lv
>> > 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 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

2017-05-15 Thread Zheng, Lv
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 v4 2/4] ACPICA: Tables: Add mechanism to allow to balance late stage acpi_get_table() independently

2017-05-15 Thread Zheng, Lv
Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Subject: Re: [PATCH v4 2/4] ACPICA: Tables: Add mechanism to allow to balance > late stage > acpi_get_table() independently > > On Tuesday, May 09, 2017 01:57:41 PM Lv Zheng wrote: > > For all frequent late stage

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

2017-05-14 Thread Zheng, Lv
Hi, Benjamin Let's stop endless discussing and focus on our needs. I just copied my questions here. You can ask them directly. For the below inlined replies, I'll stop replying if they are based on dependent on our basic agreements. And I'll reply if something is really bad from my point of

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

2017-05-11 Thread Zheng, Lv
Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Benjamin > Tissoires > Subject: Re: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method > mode" > > On May 11 2017 or thereabouts, Zheng, Lv wrote:

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

2017-05-11 Thread Zheng, Lv
Hi, > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to > lid_init_state=open" > > On May 11 2017 or thereabouts, Zheng, Lv wrote: > > Hi, > > > > > Fr

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

2017-05-10 Thread Zheng, Lv
Hi, Benjamin > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng, > Lv > Subject: RE: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method > mode" > > Hi, Benjiamin > > > From: Be

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

2017-05-10 Thread Zheng, Lv
Hi, > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to > lid_init_state=open" > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025. > > Even if the method implementation can be buggy on some

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

2017-05-10 Thread Zheng, Lv
Hi, Benjiamin > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > Sent: Thursday, May 11, 2017 12:13 AM > To: Rafael J . Wysocki <r...@rjwysocki.net>; Zheng, Lv <lv.zh...@intel.com> > Cc: Jiri Eischmann <jeisc...@redhat.com>; linux-a...@vg

RE: [PATCH v3 2/4] ACPICA: Tables: Add mechanism to allow to balance late stage acpi_get_table() independently

2017-05-08 Thread Zheng, Lv
May 04, 2017 07:18:28 AM Zheng, Lv wrote: > > 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 v3 2/4] ACPICA: Table

RE: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

2017-05-04 Thread Zheng, Lv
Hi, > From: Jon Mason [mailto:jon.ma...@broadcom.com] > Sent: Thursday, May 4, 2017 11:06 PM > Subject: [PATCH] ACPI: SPCR: Use access width to determine mmio usage > > The current SPCR code does not check the access width of the mmio, and > uses a default of 8bit register accesses. This

RE: [PATCH v3 2/4] ACPICA: Tables: Add mechanism to allow to balance late stage acpi_get_table() independently

2017-05-04 Thread Zheng, Lv
Hi, Dan > From: Dan Williams [mailto:dan.j.willi...@intel.com] > Sent: Thursday, May 4, 2017 11:45 PM > Subject: Re: [PATCH v3 2/4] ACPICA: Tables: Add mechanism to allow to balance > late stage > acpi_get_table() independently > > On Thu, May 4, 2017 at 12:18 AM, Zheng, L

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

2017-05-04 Thread Zheng, Lv
Hi, > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Subject: Re: [PATCH 3/5] ACPI / sleep: EC-based wakeup from suspend-to-idle > on Dell systems > > On Thursday, May 04, 2017 04:23:30 PM Rafael J. Wysocki wrote: > > On Thursday, May 04, 2017 07:58:53 AM Zhen

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

2017-05-04 Thread Zheng, Lv
Hi, > -Original Message- > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. > Wysocki > Sent: Friday, April 28, 2017 6:26 AM > To: mario.limoncie...@dell.com > Cc: linux...@vger.kernel.org; andriy.shevche...@linux.intel.com; >

RE: [PATCH v3 2/4] ACPICA: Tables: Add mechanism to allow to balance late stage acpi_get_table() independently

2017-05-04 Thread Zheng, Lv
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 v3 2/4] ACPICA: Tables: Add mechanism to allow to balance > late stage > acpi_get_table() independently > > On Friday, April 28, 2017 01:30:20

RE: [PATCH v2 1/2] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

2017-04-27 Thread Zheng, Lv
Hi, Rafael I reconsidered your comments. Seems there are several problems you might not be aware of. Let me reply again. > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. > Wysocki > Subject: Re: [PATCH v2 1/2] ACPICA: Tables: Fix

RE: [PATCH v2 1/2] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

2017-04-27 Thread Zheng, Lv
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 1/2] ACPICA: Tables: Fix regression introduced by a > too early mechanism > enabling > > On Thursday, April 27, 2017 04:22:44 PM Lv Zheng

RE: [PATCH v2] acpi: fix acpi_get_table() leak / acpi-sysfs denial of service

2017-04-27 Thread Zheng, Lv
Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Dan > Williams > Subject: Re: [PATCH v2] acpi: fix acpi_get_table() leak / acpi-sysfs denial > of service > > On Wed, Apr 26, 2017 at 11:49 PM, Zheng, Lv <lv.zh...@

RE: [PATCH v2] acpi: fix acpi_get_table() leak / acpi-sysfs denial of service

2017-04-27 Thread Zheng, Lv
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] acpi: fix acpi_get_table() leak / acpi-sysfs denial > of service > > On Tue, Apr 25, 2017 at 9:58 PM, Dan Williams

RE: [RFC PATCH] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

2017-04-25 Thread Zheng, Lv
Hi, > From: Dan Williams [mailto:dan.j.willi...@intel.com] > Subject: Re: [RFC PATCH] ACPICA: Tables: Fix regression introduced by a too > early mechanism enabling > > On Tue, Apr 25, 2017 at 6:49 PM, Lv Zheng wrote: > > In the Linux kernel side, acpi_get_table() hasn't

RE: [PATCH] acpi: fix acpi_get_table() leak / acpi-sysfs denial of service

2017-04-25 Thread Zheng, Lv
Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Dan > Williams > Subject: [PATCH] acpi: fix acpi_get_table() leak / acpi-sysfs denial of > service > > Reading an ACPI table through the /sys/firmware/acpi/tables interface > more than 65,536

RE: [PATCH] ACPICA: Export mutex functions

2017-04-18 Thread Zheng, Lv
Hi, > From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv > Subject: Re: [Devel] [PATCH] ACPICA: Export mutex functions > > Hi, > > > From: Guenter Roeck [mailto:li...@roeck-us.net] > > Subject: Re: [PATCH] ACPICA: Export mutex functions > >

RE: [PATCH] ACPICA: Export mutex functions

2017-04-18 Thread Zheng, Lv
Hi, > From: Guenter Roeck [mailto:li...@roeck-us.net] > Subject: Re: [PATCH] ACPICA: Export mutex functions > > On 04/18/2017 12:14 AM, Zheng, Lv wrote: > > Hi, > > > >> From: Zheng, Lv > >> Subject: RE: [PATCH] ACPICA: Export mutex functions &g

RE: [PATCH] ACPICA: Export mutex functions

2017-04-18 Thread Zheng, Lv
Hi, > From: Zheng, Lv > Subject: RE: [PATCH] ACPICA: Export mutex functions > > Hi, > > > From: Guenter Roeck [mailto:li...@roeck-us.net] > > Subject: Re: [PATCH] ACPICA: Export mutex functions > > > > On 04/17/2017 04:53 PM, Zheng, Lv wrote: >

RE: [PATCH] ACPICA: Export mutex functions

2017-04-18 Thread Zheng, Lv
Hi, > From: Guenter Roeck [mailto:li...@roeck-us.net] > Subject: Re: [PATCH] ACPICA: Export mutex functions > > On 04/17/2017 04:53 PM, Zheng, Lv wrote: > > Hi, > > > >> From: Guenter Roeck [mailto:li...@roeck-us.net] > >> Subject: Re: [PATCH] ACPICA: Ex

RE: [PATCH] ACPICA: Export mutex functions

2017-04-17 Thread Zheng, Lv
Hi, > From: Guenter Roeck [mailto:li...@roeck-us.net] > Subject: Re: [PATCH] ACPICA: Export mutex functions > > On Mon, Apr 17, 2017 at 11:29:38PM +0200, Rafael J. Wysocki wrote: > > On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck wrote: > > > On Mon, Apr 17, 2017 at

RE: [PATCH] ACPICA: Export mutex functions

2017-04-17 Thread Zheng, Lv
From: Moore, Robert > > > Sent: Monday, April 17, 2017 10:13 AM > > > To: Guenter Roeck <li...@roeck-us.net>; Zheng, Lv <lv.zh...@intel.com> > > > Cc: Wysocki, Rafael J <rafael.j.wyso...@intel.com>; Len Brown > > > <l...@kernel.org>;

RE: [PATCH] ACPICA: Export mutex functions

2017-04-17 Thread Zheng, Lv
Hi, > -Original Message- > From: Moore, Robert > Sent: Tuesday, April 18, 2017 3:28 AM > To: 'Guenter Roeck' <li...@roeck-us.net>; Zheng, Lv <lv.zh...@intel.com> > Cc: Wysocki, Rafael J <rafael.j.wyso...@intel.com>; 'Len Brown' > <l...@kernel.org&g

RE: [PATCH] ACPICA: Export mutex functions

2017-04-17 Thread Zheng, Lv
Hi, > From: Guenter Roeck [mailto:li...@roeck-us.net] > Subject: Re: [PATCH] ACPICA: Export mutex functions > > Hi, > > On Mon, Apr 17, 2017 at 09:39:35AM +, Zheng, Lv wrote: > > Hi, > > > > > From: Guenter Roeck [mailto:li...@roeck-us.net] > >

RE: [PATCH] ACPICA: Export mutex functions

2017-04-17 Thread Zheng, Lv
Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Guenter > Roeck > Subject: Re: [PATCH] ACPICA: Export mutex functions > > On 04/17/2017 02:48 AM, Zheng, Lv wrote: > > Hi, > > > >> From: Devel [mai

RE: [PATCH] ACPICA: Export mutex functions

2017-04-17 Thread Zheng, Lv
Hi, > From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv > Sent: Monday, April 17, 2017 5:40 PM > To: Guenter Roeck <li...@roeck-us.net>; Moore, Robert <robert.mo...@intel.com> > Cc: linux-a...@vger.kernel.org; de...@acpica.org; Wysocki, Rafael J >

RE: [PATCH] ACPICA: Export mutex functions

2017-04-17 Thread Zheng, Lv
o the resource(s) protected > by MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ? > > Outch. Really ? > > Thanks, > Guenter > > > > > > -Original Message- > > > From: Guenter Roeck [mailto:li...@roeck-us.net] > > > Sent:

RE: [PATCH] ACPICA: use designated initializers

2017-03-29 Thread Zheng, Lv
Hi, > From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees Cook > Subject: Re: [PATCH] ACPICA: use designated initializers > > On Sun, Dec 18, 2016 at 10:06 PM, Zheng, Lv <lv.zh...@intel.com> wrote: > > Hi, > > > >> From: Kees Cook [mai

RE: [PATCH v2] acpi: acpica: fix acpi operand cache leak

2017-02-28 Thread Zheng, Lv
rt which has the root cause of this problem below. > > 2017-02-27 11:45 GMT+09:00 Zheng, Lv <lv.zh...@intel.com>: > > Hi, Rafael > > > >> From: linux-acpi-ow...@vger.kernel.org > >> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of > Rafael J. > &

RE: [PATCH v2] acpi: acpica: fix acpi operand cache leak

2017-02-26 Thread Zheng, Lv
t; >> >> Hi, Lv Zheng. > >>> >> >> > >>> >> >> I added my handcrafted ACPI table under your request, because > >>> >> >> "acpidump -c on" and "acpidump -c off" does

RE: [PATCH] acpica: Fix double-free in acpi_ns_repair_CID()

2017-02-05 Thread Zheng, Lv
Hi, So if a real problem related to package reference counting is triggered, the problem should be fixed elsewhere IMO. See this bug for reference: https://bugs.acpica.org/show_bug.cgi?id=1336 Thanks and best regards Lv > From: Moore, Robert > Subject: RE: [PATCH] acpica: Fix double-free in

RE: [PATCH] rcu: Narrow early boot window of illegal synchronous grace periods

2017-01-15 Thread Zheng, Lv
Hi, > From: Borislav Petkov [mailto:b...@alien8.de] > Subject: Re: [PATCH] rcu: Narrow early boot window of illegal synchronous > grace periods > > On Sat, Jan 14, 2017 at 01:27:40PM +0100, Rafael J. Wysocki wrote: > > OK, so this fixes the problem with synchronize_rcu_expedited() in > >

RE: [lkp-developer] [ACPICA] 174cc7187e: kmsg.ACPI_Error:Mutex[ACPI_MTX_Tables]already_acquired_by_this_thread[#](#/utmutex-#)

2017-01-11 Thread Zheng, Lv
Hi, Xiaolong I noticed the tested version in your the test dmesg: Linux version 4.9.0-rc5 While the commit bisected should be in v4.10-rc1. Does that mean your test tree doesn't contain some basic lock fixes? Thanks and best regards Lv > From: lkp-developer-requ...@eclists.intel.com >

RE: [PATCH] ACPI / OSL: Fix rcu synchronization logic

2017-01-09 Thread Zheng, Lv
Hi, Rafael > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J. > Wysocki > Sent: Tuesday, January 10, 2017 7:35 AM > Subject: Re: [PATCH] ACPI / OSL: Fix rcu synchronization logic > > On Mon, Jan 9, 2017 at 10:56 AM, Lv Zheng wrote: > > The rcu

RE: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

2017-01-09 Thread Zheng, Lv
Hi, Rafael and Paul > From: Paul E. McKenney [mailto:paul...@linux.vnet.ibm.com] > Subject: Re: 174cc7187e6f ACPICA: Tables: Back port > acpi_get_table_with_size() and > early_acpi_os_unmap_memory() from Linux kernel > > On Tue, Jan 10, 2017 at 02:27:16AM +0100, Rafael J. Wysocki wrote: > > On

RE: [PATCH] ACPI / OSL: Fix rcu synchronization logic

2017-01-09 Thread Zheng, Lv
Hi, Borislav > From: Borislav Petkov [mailto:b...@alien8.de] > Subject: Re: [PATCH] ACPI / OSL: Fix rcu synchronization logic > > On Mon, Jan 09, 2017 at 05:56:09PM +0800, Lv Zheng wrote: > > The rcu synchronization logic is originally provided to protect > > apei_read()/apei_write() as in the

RE: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

2017-01-09 Thread Zheng, Lv
Hi, Can the attached patch makes something different? Thanks and best regards Lv > From: Borislav Petkov [mailto:b...@alien8.de] > Subject: Re: 174cc7187e6f ACPICA: Tables: Back port > acpi_get_table_with_size() and > early_acpi_os_unmap_memory() from Linux kernel > > On Tue, Jan 10, 2017 at

RE: [PATCH] ACPI / EC: Use busy polling mode when GPE is not enabled

2017-01-08 Thread Zheng, Lv
Hi, Yu > From: Chen, Yu C > Subject: [PATCH] ACPI / EC: Use busy polling mode when GPE is not enabled > > From: Lv Zheng > > Previously we have report that during system bootup, the EC command > was running too slow because the EC GPE has not been enabled yet > (For

RE: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

2017-01-08 Thread Zheng, Lv
Hi, Borislav > From: Zheng, Lv > Subject: RE: 174cc7187e6f ACPICA: Tables: Back port > acpi_get_table_with_size() and > early_acpi_os_unmap_memory() from Linux kernel > > Hi, > > > From: linux-acpi-ow...@vger.kernel.org > > [mailto:linux-acpi-ow...@vger.kerne

RE: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

2017-01-08 Thread Zheng, Lv
Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng, > Lv > Subject: RE: 174cc7187e6f ACPICA: Tables: Back port > acpi_get_table_with_size() and > early_acpi_os_unmap_memory() from Linux kernel > > Hi, &g

RE: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

2017-01-08 Thread Zheng, Lv
Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Borislav > Petkov > Subject: Re: 174cc7187e6f ACPICA: Tables: Back port > acpi_get_table_with_size() and > early_acpi_os_unmap_memory() from Linux kernel > > On Sun, Jan 08, 2017 at 03:20:20AM

RE: [PATCH] ACPI / DMAR: Avoid passing NULL to acpi_put_table()

2017-01-05 Thread Zheng, Lv
Hi, Rafael > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. > Wysocki > Subject: [PATCH] ACPI / DMAR: Avoid passing NULL to acpi_put_table() > > From: Rafael J. Wysocki > > Linus reported that commit

RE: [GIT PULL] More ACPI updates for v4.10-rc1

2017-01-04 Thread Zheng, Lv
Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zhang > Rui > Subject: Re: [GIT PULL] More ACPI updates for v4.10-rc1 > > On Wed, 2017-01-04 at 09:46 -0800, Linus Torvalds wrote: > > On Thu, Dec 22, 2016 at 6:18 AM, Rafael J. Wysocki

RE: [PATCH 00/18] ACPICA 20161222 Release

2017-01-02 Thread Zheng, Lv
Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Subject: Re: [PATCH 00/18] ACPICA 20161222 Release > > On Wednesday, December 28, 2016 03:28:00 PM Lv Zheng wrote: > > The 20161222 ACPICA kernel-resident subsystem updates are linuxized based > > on the linux-pm/linux-next

RE: Question regarding power button of Dell XPS13

2016-12-27 Thread Zheng, Lv
Hi, Paul > From: Paul Menzel [mailto:pmen...@molgen.mpg.de] > Subject: Question regarding power button of Dell XPS13 > > Dear Linus, dear Len, > > > I heard that you both have a Dell XPS13. I got the “revision” 9360, and > installed Debian Stretch/testing on it with Linux 4.8.15 and Linux

RE: [PATCH] acpi: Fix format string type mistakes

2016-12-21 Thread Zheng, Lv
g type mistakes > > These formatting changes will not compile under: > > Gcc 4.4.5 > Gcc 5.4.0 > > The printf formatting stuff is very delicate, as ACPICA has to be compiled > under many different > compilers. > > Bob > > > From: Zheng, Lv > > Subj

RE: [PATCH] acpi: Fix format string type mistakes

2016-12-21 Thread Zheng, Lv
Hi, Kees and Emese The pull request is under rebasing. So if you cannot reach the URL, find the commit here: https://github.com/acpica/acpica/pull/196 Thanks and best regards Lv > From: Zheng, Lv > Subject: RE: [PATCH] acpi: Fix format string type mistakes > > Hi, Kees and Emese

  1   2   3   4   5   >