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
> > mo
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: l
st v5 when 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
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 usi
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: Cha
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: 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 platform firmware expects GPEs to b
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,
> 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
> > @@ -2139
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 b
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 du
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 f712c71f7b2b ("ACPI, APEI: Fixup commo
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
> ; 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
> > s
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 suspen
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
> wrote
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, 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, incl
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 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, 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, 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 Poet
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 end,
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: 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
> pr
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 platforms
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).
>
> So
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 \
> acpi-4
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 noti
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:
> > Th
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 answe
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
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, 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 acpi_get_table()
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 view
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:
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
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
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 plat
Hi, Benjiamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Sent: Thursday, May 11, 2017 12:13 AM
> To: Rafael J . Wysocki ; Zheng, Lv
> Cc: Jiri Eischmann ; linux-a...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: [PATCH 1/2] Revert &quo
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
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 prevent
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, Zhe
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
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;
> dvh.
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 P
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 regress
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 wro
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 wrote:
> &g
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
> wrote:
> > Reading an
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 been fully balanced by
>
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 t
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
> >
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
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:
>
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
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 08:40:38PM +, Moore, Rob
From: Moore, Robert
> > > Sent: Monday, April 17, 2017 10:13 AM
> > > To: Guenter Roeck ; Zheng, Lv
> > > Cc: Wysocki, Rafael J ; Len Brown
> > > ; linux-a...@vger.kernel.org; de...@acpica.org; linux-
> > > ker...@vger.kernel.org
> > > Subjec
Hi,
> -Original Message-
> From: Moore, Robert
> Sent: Tuesday, April 18, 2017 3:28 AM
> To: 'Guenter Roeck' ; Zheng, Lv
> Cc: Wysocki, Rafael J ; 'Len Brown'
> ; 'linux-
> a...@vger.kernel.org' ; 'de...@acpica.org'
> ; &#
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]
> >
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 [mailto
Hi,
> From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv
> Sent: Monday, April 17, 2017 5:40 PM
> To: Guenter Roeck ; Moore, Robert
> Cc: linux-a...@vger.kernel.org; de...@acpica.org; Wysocki, Rafael J
> ;
> linux-kernel@vger.kernel.org
> Subject: Re: [
e exclusive access to 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]
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 wrote:
> > Hi,
> >
> >> From: Kees Cook [mailto:keesc...@chromium.org]
which has the root cause of this problem below.
>
> 2017-02-27 11:45 GMT+09:00 Zheng, Lv :
> > Hi, Rafael
> >
> >> From: linux-acpi-ow...@vger.kernel.org
> >> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of
> Rafael J.
> >> Wysocki
> >>
t; I added my handcrafted ACPI table under your request, because
> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >>> >> >>
> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>
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 acp
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
> > acpi_os
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
> [mailto:l
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 synchronization logic
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 T
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 AP
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 1
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 example, _REG tries to acces
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
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
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
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 174cc7187e6f "ACPICA: Tables: Back
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 > > wro
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 branch
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 4.9-r
string 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
> >
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 - 100 of 459 matches
Mail list logo
