RE: [BUG] ODEBUG: assert_init not available (active state 0)

Hi, The below change is spec compliant. I think you should first test again after the RefOrName stuffs reverted. Then, if you still can see the issues, the story is: === We are enabling correct initialization order and table parsing facilities. These patches are part of them. === So you could

RE: [BUG] ODEBUG: assert_init not available (active state 0)

Hi, The below change is spec compliant. I think you should first test again after the RefOrName stuffs reverted. Then, if you still can see the issues, the story is: === We are enabling correct initialization order and table parsing facilities. These patches are part of them. === So you could

RE: [PATCH] ACPICA: Drop Linux-specific waking vector functions

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Monday, January 4, 2016 9:28 PM > Subject: Re: [PATCH] ACPICA: Drop Linux-specific waking vector functions > > On Monday, January 04, 2016 07:33:55 AM Zheng, Lv wrote: > > Hi, Rafael > > > &g

RE: [PATCH] ACPICA: Drop Linux-specific waking vector functions

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Monday, January 4, 2016 9:28 PM > Subject: Re: [PATCH] ACPICA: Drop Linux-specific waking vector functions > > On Monday, January 04, 2016 07:33:55 AM Zheng, Lv wrote: > > Hi, Rafael > > &

RE: [PATCH] ACPICA: Drop Linux-specific waking vector functions

Hi, Rafael Acke-by: Lv Zheng One more improvement is: After applying this patch, I can still detect the following diff blocks using ACPICA's divergence checking utility: diff -E -b -w -B -rpuN linux-acpica/drivers/acpi/acpica/hwxfsleep.c acpica-linuxized/drivers/acpi/acpica/hwxfsleep.c ---

RE: [PATCH 00/42] ACPICA: 20151218 Release

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Friday, January 1, 2016 11:05 AM > Subject: Re: [PATCH 00/42] ACPICA: 20151218 Release > > On Tuesday, December 29, 2015 01:52:19 PM Lv Zheng wrote: > > The 20151218 ACPICA kernel-resident subsystem updates are linuxized

RE: [PATCH 00/42] ACPICA: 20151218 Release

should probably be > documented > in the patch bundle and it's explination. [Lv Zheng] Yes. This is a good idea. I'll prepare the documentation. Thanks and best regards -Lv > > David Lang > > On Tue, 29 Dec 2015, Lv Zheng wrote: > > > Date: Tue, 29 Dec 2015 13:52:19

RE: [PATCH 00/42] ACPICA: 20151218 Release

Hi, > From: David Lang [mailto:da...@lang.hm] > Sent: Sunday, January 3, 2016 2:45 PM > > what is ACPICA and why should we care about divergence between it and the > linux > upstream? Where is it to be found? [Lv Zheng] You can find ACPICA at: https://acpica.org. Source code of ACPICA can be

RE: [PATCH 00/42] ACPICA: 20151218 Release

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Friday, January 1, 2016 11:05 AM > Subject: Re: [PATCH 00/42] ACPICA: 20151218 Release > > On Tuesday, December 29, 2015 01:52:19 PM Lv Zheng wrote: > > The 20151218 ACPICA kernel-resident subsystem updates are linuxized

RE: [PATCH] ACPICA: Drop Linux-specific waking vector functions

Hi, Rafael Acke-by: Lv Zheng One more improvement is: After applying this patch, I can still detect the following diff blocks using ACPICA's divergence checking utility: diff -E -b -w -B -rpuN linux-acpica/drivers/acpi/acpica/hwxfsleep.c

RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support

:03 PM, Chen, Yu C wrote: > > Hi Andy, > > thanks for your review, > > > >> -Original Message- > >> From: Andy Lutomirski [mailto:l...@amacapital.net] > >> Sent: Friday, December 18, 2015 1:00 AM > >> To: Zheng, Lv > >> Cc: C

RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support

:03 PM, Chen, Yu C <yu.c.c...@intel.com> wrote: > > Hi Andy, > > thanks for your review, > > > >> -Original Message- > >> From: Andy Lutomirski [mailto:l...@amacapital.net] > >> Sent: Friday, December 18, 2015 1:00 AM > >> To: Zhe

RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support

Hi, Andy and Yu > From: Zheng, Lv > Sent: Tuesday, December 15, 2015 4:52 PM > > Hi, > > > From: Chen, Yu C > > Sent: Tuesday, December 15, 2015 2:13 PM > > > > Hi, Andy > > > > > From: Andy Lutomirski [mailto:l...@amacapit

RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support

Hi, > From: Chen, Yu C > Sent: Tuesday, December 15, 2015 2:13 PM > > Hi, Andy > > > From: Andy Lutomirski [mailto:l...@amacapital.net] > > Sent: Tuesday, December 15, 2015 7:28 AM > > > > On Wed, Dec 2, 2015 at 6:43 PM, Lv Zheng wrote: > > > From: Chen Yu > > > > > > This patch implements

RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support

Hi, > From: Chen, Yu C > Sent: Tuesday, December 15, 2015 2:13 PM > > Hi, Andy > > > From: Andy Lutomirski [mailto:l...@amacapital.net] > > Sent: Tuesday, December 15, 2015 7:28 AM > > > > On Wed, Dec 2, 2015 at 6:43 PM, Lv Zheng wrote: > > > From: Chen Yu

RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support

Hi, Andy and Yu > From: Zheng, Lv > Sent: Tuesday, December 15, 2015 4:52 PM > > Hi, > > > From: Chen, Yu C > > Sent: Tuesday, December 15, 2015 2:13 PM > > > > Hi, Andy > > > > > From: Andy Lutomirski [mailto:l...@amacapit

RE: [PATCH v4 0/7] ACPICA / debugger: Add in-kernel AML debugger support

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Tuesday, December 15, 2015 7:45 AM > > On Thursday, December 03, 2015 10:40:00 AM Lv Zheng wrote: > > This patchset enables ACPICA debugger for Linux kernel and implements a > > userspace utility to access it. > > > > A.

RE: [PATCH v4 0/7] ACPICA / debugger: Add in-kernel AML debugger support

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Tuesday, December 15, 2015 7:45 AM > > On Thursday, December 03, 2015 10:40:00 AM Lv Zheng wrote: > > This patchset enables ACPICA debugger for Linux kernel and implements a > > userspace utility to access it. > > > > A.

RE: overriding ACPI _CRS method

Hi, IMO, if you want the new _CRS to be applied during the Linux early boot stage, you can override the table using initrd override or DSDT override mechanism. Please see Documentation/acpi/initrd_table_override.txt or Documentation/acpi/dsdt-override.txt. If you want the new _CRS to be

RE: overriding ACPI _CRS method

Hi, IMO, if you want the new _CRS to be applied during the Linux early boot stage, you can override the table using initrd override or DSDT override mechanism. Please see Documentation/acpi/initrd_table_override.txt or Documentation/acpi/dsdt-override.txt. If you want the new _CRS to be

RE: [PATCH v2 5/7] ACPI / x86: introduce acpi_os_readable() support

Hi, Yu > From: Zheng, Lv > Sent: Wednesday, November 11, 2015 1:07 PM > > Hi, Yu > > > From: Chen, Yu C > > Sent: Tuesday, November 10, 2015 5:43 PM > > > > Hi, Lv > > Sorry for my late feedback on the patch, one minor nit below: > > > >

RE: [PATCH v2 5/7] ACPI / x86: introduce acpi_os_readable() support

Hi, Yu > From: Zheng, Lv > Sent: Wednesday, November 11, 2015 1:07 PM > > Hi, Yu > > > From: Chen, Yu C > > Sent: Tuesday, November 10, 2015 5:43 PM > > > > Hi, Lv > > Sorry for my late feedback on the patch, one minor nit below: > > > >

RE: [PATCH v2 5/7] ACPI / x86: introduce acpi_os_readable() support

Hi, Yu > From: Chen, Yu C > Sent: Tuesday, November 10, 2015 5:43 PM > > Hi, Lv > Sorry for my late feedback on the patch, one minor nit below: > > > From: Zheng, Lv > > Sent: Tuesday, November 10, 2015 4:22 PM > > > > From: Chen Yu >

RE: [PATCH v2 5/7] ACPI / x86: introduce acpi_os_readable() support

Hi, Yu > From: Chen, Yu C > Sent: Tuesday, November 10, 2015 5:43 PM > > Hi, Lv > Sorry for my late feedback on the patch, one minor nit below: > > > From: Zheng, Lv > > Sent: Tuesday, November 10, 2015 4:22 PM > > > > From: Chen Yu <yu.c.

RE: [PATCH 3.4 52/65] ACPICA: Tables: Fix an issue that FACS initialization is performed twice

Hi, > From: Moore, Robert > Sent: Tuesday, October 20, 2015 9:35 PM > > > > > -Original Message- > > From: l...@kernel.org [mailto:l...@kernel.org] > > Sent: Monday, October 19, 2015 5:48 PM > > To: sta...@vger.kernel.org > > Cc: linux-ker

RE: [PATCH v2 09/14] ACPICA: Debugger: Fix "quit/exit" command by cleaning up user commands termination logic

org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng, Lv > Sent: Tuesday, October 20, 2015 10:04 AM > > I was using linux-pm.git/linux-next base which I downloaded a week ago. > Maybe the conflict was caused by the fast-path ACPICA table fix merged after > my downlo

RE: [PATCH v2 09/14] ACPICA: Debugger: Fix "quit/exit" command by cleaning up user commands termination logic

org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng, Lv > Sent: Tuesday, October 20, 2015 10:04 AM > > I was using linux-pm.git/linux-next base which I downloaded a week ago. > Maybe the conflict was caused by the fast-path ACPICA table fix merged after > my downlo

RE: [PATCH 3.4 52/65] ACPICA: Tables: Fix an issue that FACS initialization is performed twice

Hi, > From: Moore, Robert > Sent: Tuesday, October 20, 2015 9:35 PM > > > > > -Original Message- > > From: l...@kernel.org [mailto:l...@kernel.org] > > Sent: Monday, October 19, 2015 5:48 PM > > To: sta...@vger.kernel.org > > Cc: linux-ker

RE: [PATCH v2 09/14] ACPICA: Debugger: Fix "quit/exit" command by cleaning up user commands termination logic

I was using linux-pm.git/linux-next base which I downloaded a week ago. Maybe the conflict was caused by the fast-path ACPICA table fix merged after my downloading. Let me check again. Thanks and best regards -Lv > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Tuesday, October 20,

RE: [PATCH v2 09/14] ACPICA: Debugger: Fix "quit/exit" command by cleaning up user commands termination logic

I was using linux-pm.git/linux-next base which I downloaded a week ago. Maybe the conflict was caused by the fast-path ACPICA table fix merged after my downloading. Let me check again. Thanks and best regards -Lv > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Tuesday, October 20,

RE: [PATCH 01/13] ACPICA: Remove unnecessary conditional compilation.

going to let Lv take a look at this. > Bob > > > > > -Original Message- > > From: lkp > > Sent: Thursday, October 15, 2015 8:51 AM > > To: Zheng, Lv > > Cc: kbuild-...@01.org; Wysocki, Rafael J; Brown, Len; Zheng, Lv; Lv Zheng; > > linux-ke

RE: [PATCH 01/13] ACPICA: Remove unnecessary conditional compilation.

going to let Lv take a look at this. > Bob > > > > > -Original Message- > > From: lkp > > Sent: Thursday, October 15, 2015 8:51 AM > > To: Zheng, Lv > > Cc: kbuild-...@01.org; Wysocki, Rafael J; Brown, Len; Zheng, Lv; Lv Zheng; > > linux-ke

RE: bisected: Re: 4.3.0-rc3-00042: ACPI Warning: AcpiEnable failed

Hi, > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Tuesday, October 13, 2015 3:19 AM > > On Monday, October 12, 2015 07:48:12 AM Zheng, Lv wrote: > > Hi, Rafael > > Hi, > > > The bug has been fixed. > > The root cause is the previ

RE: bisected: Re: 4.3.0-rc3-00042: ACPI Warning: AcpiEnable failed

Hi, > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Tuesday, October 13, 2015 3:19 AM > > On Monday, October 12, 2015 07:48:12 AM Zheng, Lv wrote: > > Hi, Rafael > > Hi, > > > The bug has been fixed. > > The root cause is the previ

RE: bisected: Re: 4.3.0-rc3-00042: ACPI Warning: AcpiEnable failed

Hi, Rafael The bug has been fixed. The root cause is the previous commit doesn't cover a hidden logic: acpi_enable() should rely on the existence of FADT while currently it relies on the number of loaded tables. The fix that removes the hidden logic is an ACPICA commit. Shall we wait until it

RE: bisected: Re: 4.3.0-rc3-00042: ACPI Warning: AcpiEnable failed

Hi, Rafael The bug has been fixed. The root cause is the previous commit doesn't cover a hidden logic: acpi_enable() should rely on the existence of FADT while currently it relies on the number of loaded tables. The fix that removes the hidden logic is an ACPICA commit. Shall we wait until it

RE: [PATCH][v3] ACPI / PM: Fix incorrect wakeup irq setting before suspend-to-idle

Hi, > From: Chen, Yu C > Sent: Friday, October 09, 2015 5:50 PM > > Hi, LV > > > From: Zheng, Lv > > Sent: Friday, October 09, 2015 4:33 PM > > > > Hi, Yu > > > > > From: Chen, Yu C > > > Sent: Friday, October 09, 2015 4:20 PM >

RE: [PATCH][v3] ACPI / PM: Fix incorrect wakeup irq setting before suspend-to-idle

Hi, Yu > From: Chen, Yu C > Sent: Friday, October 09, 2015 4:20 PM > > For ACPI compatible system, SCI(ACPI System Control > Interrupt) is used to wake system up from suspend-to-idle. > Once CPU is woken up by SCI, interrupt handler will > firstly checks if current interrupt is legal to wake up

RE: [PATCH][v3] ACPI / PM: Fix incorrect wakeup irq setting before suspend-to-idle

Hi, Yu > From: Chen, Yu C > Sent: Friday, October 09, 2015 4:20 PM > > For ACPI compatible system, SCI(ACPI System Control > Interrupt) is used to wake system up from suspend-to-idle. > Once CPU is woken up by SCI, interrupt handler will > firstly checks if current interrupt is legal to wake up

RE: [PATCH][v3] ACPI / PM: Fix incorrect wakeup irq setting before suspend-to-idle

Hi, > From: Chen, Yu C > Sent: Friday, October 09, 2015 5:50 PM > > Hi, LV > > > From: Zheng, Lv > > Sent: Friday, October 09, 2015 4:33 PM > > > > Hi, Yu > > > > > From: Chen, Yu C > > > Sent: Friday, October 09, 2015 4:20 PM >

[RFC] ECDT support in early stage

There are many ECDT quirks in drivers/acpi/ec.c. I tracked the commit log back to learn what was happening on each ECDT related commits. My observation result is: For ACPI 2.0+ compliant platforms, where ECDT may be introduced, the BIOSes that contain the ECDT will make the named object's value

[RFC] ECDT support in early stage

There are many ECDT quirks in drivers/acpi/ec.c. I tracked the commit log back to learn what was happening on each ECDT related commits. My observation result is: For ACPI 2.0+ compliant platforms, where ECDT may be introduced, the BIOSes that contain the ECDT will make the named object's value

RE: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

Hi, > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Wednesday, September 16, 2015 9:57 AM > > On Tuesday, September 15, 2015 02:04:58 PM Viresh Kumar wrote: > > global_lock is defined as an unsigned long and accessing only its lower > > 32 bits from sysfs is incorrect, as we need

RE: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

Hi, > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Wednesday, September 16, 2015 9:57 AM > > On Tuesday, September 15, 2015 02:04:58 PM Viresh Kumar wrote: > > global_lock is defined as an unsigned long and accessing only its lower > > 32 bits from sysfs is incorrect, as we need

RE: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type

Hi, Ville Have you reported this to the owner of the backlight core? This looks like a bug that the backlight core should handle. What intel backlight driver and acpi backlight driver have done here are just invoking APIs provided by the backlight core. So it is the duty of the backlight core to

RE: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type

Hi, Ville Have you reported this to the owner of the backlight core? This looks like a bug that the backlight core should handle. What intel backlight driver and acpi backlight driver have done here are just invoking APIs provided by the backlight core. So it is the duty of the backlight core to

RE: [PATCH 00/22] ACPICA: 20150717 Release

Hi, Rafael You may also need this patch: https://patchwork.kernel.org/patch/6879621/ Which fixes a problem in this release. Sorry for noticing this late. Thanks and best regards -Lv > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Wednesday, July 29, 2015 8:58 AM > > On Thursday,

RE: [PATCH 00/22] ACPICA: 20150717 Release

Hi, Rafael You may also need this patch: https://patchwork.kernel.org/patch/6879621/ Which fixes a problem in this release. Sorry for noticing this late. Thanks and best regards -Lv From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Wednesday, July 29, 2015 8:58 AM On Thursday,

RE: [PATCH 0/4] ACPI: Update method tracing facility.

Hi, Rafael > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki > Sent: Saturday, July 25, 2015 3:56 AM > > On Friday, July 24, 2015 02:02:33 AM Zheng, Lv wrote: > > Hi, Rafael > > Hi, > > > ACP

RE: [PATCH 0/4] ACPI: Update method tracing facility.

Hi, Rafael From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki Sent: Saturday, July 25, 2015 3:56 AM On Friday, July 24, 2015 02:02:33 AM Zheng, Lv wrote: Hi, Rafael Hi, ACPICA logs contain details (trace logs) that may

RE: [PATCH 0/4] ACPI: Update method tracing facility.

Hi, Rafael ACPICA logs contain details (trace logs) that may be useful for development. But the quantity of the trace logs are huge to be put into the kernel log buffer. Originally, we have a "trace log reducer" in /sys/modules/acpi/parameter, it is the method tracing facility. We can specify a

RE: [PATCH 0/4] ACPI: Update method tracing facility.

Hi, Rafael ACPICA logs contain details (trace logs) that may be useful for development. But the quantity of the trace logs are huge to be put into the kernel log buffer. Originally, we have a trace log reducer in /sys/modules/acpi/parameter, it is the method tracing facility. We can specify a

RE: Ghost Lid switch on Baytrail tablet

accessory is not plugged in. Thanks -Lv > From: Zheng, Lv > Sent: Tuesday, July 21, 2015 8:23 AM > > Hi, > > The _LID returns LIDS: > Device (LID) > { > Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: > Hardware ID &g

RE: Ghost Lid switch on Baytrail tablet

Hi, The _LID returns LIDS: Device (LID) { Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID Name (LIDS, Zero) Method (_LID, 0, NotSerialized) // _LID: Lid Status { Return (LIDS) /*

RE: Ghost Lid switch on Baytrail tablet

is not plugged in. Thanks -Lv From: Zheng, Lv Sent: Tuesday, July 21, 2015 8:23 AM Hi, The _LID returns LIDS: Device (LID) { Name (_HID, EisaId (PNP0C0D) /* Lid Device */) // _HID: Hardware ID Name (LIDS, Zero) Method (_LID, 0

RE: Ghost Lid switch on Baytrail tablet

Hi, The _LID returns LIDS: Device (LID) { Name (_HID, EisaId (PNP0C0D) /* Lid Device */) // _HID: Hardware ID Name (LIDS, Zero) Method (_LID, 0, NotSerialized) // _LID: Lid Status { Return (LIDS) /* \_SB_.LID_.LIDS

RE: [PATCH v3 00/26] ACPICA: 20150619 Release

Hi, > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Thursday, July 02, 2015 7:15 AM > > On Wednesday, July 01, 2015 02:42:39 PM Lv Zheng wrote: > > The 20150619 ACPICA kernel-resident subsystem updates are linuxized based > > on the linux-pm/linux-next branch. > > > > The patchset

RE: [PATCH v3 00/26] ACPICA: 20150619 Release

Hi, From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Thursday, July 02, 2015 7:15 AM On Wednesday, July 01, 2015 02:42:39 PM Lv Zheng wrote: The 20150619 ACPICA kernel-resident subsystem updates are linuxized based on the linux-pm/linux-next branch. The patchset has passed

RE: [PATCH v2 05/28] ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS.

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Friday, June 26, 2015 9:41 AM > > On Friday, June 26, 2015 12:51:39 AM Zheng, Lv wrote: > > Hi, Rafael > > > > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > >

RE: [PATCH v2 03/28] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Friday, June 26, 2015 9:21 AM > > On Thursday, June 25, 2015 12:29:02 AM Zheng, Lv wrote: > > Hi, Rafael > > > > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > >

RE: [PATCH v2 05/28] ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS.

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Friday, June 26, 2015 8:44 AM > > On Thursday, June 25, 2015 12:43:39 AM Zheng, Lv wrote: > > Hi, Rafael > > > > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > >

RE: [PATCH v2 03/28] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

Hi, Rafael From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Friday, June 26, 2015 9:21 AM On Thursday, June 25, 2015 12:29:02 AM Zheng, Lv wrote: Hi, Rafael From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Thursday, June 25, 2015 7:24 AM To: Zheng, Lv [cut

RE: [PATCH v2 05/28] ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS.

Hi, Rafael From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Friday, June 26, 2015 8:44 AM On Thursday, June 25, 2015 12:43:39 AM Zheng, Lv wrote: Hi, Rafael From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Thursday, June 25, 2015 7:57 AM [cut

RE: [PATCH v2 05/28] ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS.

Hi, Rafael From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Friday, June 26, 2015 9:41 AM On Friday, June 26, 2015 12:51:39 AM Zheng, Lv wrote: Hi, Rafael From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Friday, June 26, 2015 8:44 AM On Thursday, June 25

RE: [PATCH v2 03/28] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Wednesday, June 24, 2015 10:06 PM > > On Wednesday, June 24, 2015 11:02:10 AM Lv Zheng wrote: > > ACPICA commit 7aa598d711644ab0de5f70ad88f1e2de253115e4 > > > > The following commit is reported to have broken s2ram on some

RE: [PATCH v2 05/28] ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS.

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Thursday, June 25, 2015 7:57 AM > > On Wednesday, June 24, 2015 11:02:54 AM Lv Zheng wrote: > > ACPICA commit 368eb60778b27b6ae94d3658ddc902ca1342a963 > > ACPICA commit 70f62a80d65515e1285fdeeb50d94ee6f07df4bd > > > > The

RE: [PATCH v2 03/28] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Thursday, June 25, 2015 7:24 AM > To: Zheng, Lv > > On Wednesday, June 24, 2015 04:05:42 PM Rafael J. Wysocki wrote: > > On Wednesday, June 24, 2015 11:02:10 AM Lv Zheng wrote

RE: [PATCH v2 02/28] ACPICA: Linuxize: Replace __FUNCTION__ with __func__.

Hi, > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: Wednesday, June 24, 2015 8:56 PM > > On Wed, Jun 24, 2015 at 11:02:03AM +0800, Lv Zheng wrote: > > ACPICA commit cb3d1c79f862cd368d749c9b8d9dced40111b0d0 > > > > __FUNCTION__ is MSVC only, in Linux, it is __func__. Lv Zheng. > > >

RE: [PATCH v2 05/28] ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS.

Hi, Rafael From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Thursday, June 25, 2015 7:57 AM On Wednesday, June 24, 2015 11:02:54 AM Lv Zheng wrote: ACPICA commit 368eb60778b27b6ae94d3658ddc902ca1342a963 ACPICA commit 70f62a80d65515e1285fdeeb50d94ee6f07df4bd The following

RE: [PATCH v2 02/28] ACPICA: Linuxize: Replace __FUNCTION__ with __func__.

Hi, From: Christoph Hellwig [mailto:h...@infradead.org] Sent: Wednesday, June 24, 2015 8:56 PM On Wed, Jun 24, 2015 at 11:02:03AM +0800, Lv Zheng wrote: ACPICA commit cb3d1c79f862cd368d749c9b8d9dced40111b0d0 __FUNCTION__ is MSVC only, in Linux, it is __func__. Lv Zheng. In ACPICA,

RE: [PATCH v2 03/28] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

Hi, Rafael From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Wednesday, June 24, 2015 10:06 PM On Wednesday, June 24, 2015 11:02:10 AM Lv Zheng wrote: ACPICA commit 7aa598d711644ab0de5f70ad88f1e2de253115e4 The following commit is reported to have broken s2ram on some platforms:

RE: [PATCH v2 03/28] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

Hi, Rafael From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Thursday, June 25, 2015 7:24 AM To: Zheng, Lv On Wednesday, June 24, 2015 04:05:42 PM Rafael J. Wysocki wrote: On Wednesday, June 24, 2015 11:02:10 AM Lv Zheng wrote: ACPICA commit

RE: [PATCH 05/32] ACPICA: Tables: Enable both 32-bit and 64-bit FACS.

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Wednesday, June 24, 2015 8:32 AM > > On Friday, June 19, 2015 11:43:20 AM Lv Zheng wrote: > > ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486 > > > > The root cause of the reported bug might be one of the followings:

RE: [PATCH 03/32] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Wednesday, June 24, 2015 8:30 AM > > On Friday, June 19, 2015 11:38:28 AM Lv Zheng wrote: > > ACPICA commit 7aa598d711644ab0de5f70ad88f1e2de253115e4 > > > > The root cause of the reported bug might be one of the followings:

RE: [PATCH 03/32] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

Hi, Rafael > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J. > Wysocki > Sent: Tuesday, June 23, 2015 11:21 PM > > Hi Lv, > > On Fri, Jun 19, 2015 at 5:38 AM, Lv Zheng wrote: > > ACPICA commit 7aa598d711644ab0de5f70ad88f1e2de253115e4 > > > > The root cause of the

RE: [PATCH 03/32] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

Hi, Rafael From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Wednesday, June 24, 2015 8:30 AM On Friday, June 19, 2015 11:38:28 AM Lv Zheng wrote: ACPICA commit 7aa598d711644ab0de5f70ad88f1e2de253115e4 The root cause of the reported bug might be one of the followings: 1. BIOS

RE: [PATCH 05/32] ACPICA: Tables: Enable both 32-bit and 64-bit FACS.

Hi, Rafael From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Wednesday, June 24, 2015 8:32 AM On Friday, June 19, 2015 11:43:20 AM Lv Zheng wrote: ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486 The root cause of the reported bug might be one of the followings: Again,

RE: [PATCH 03/32] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

Hi, Rafael From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J. Wysocki Sent: Tuesday, June 23, 2015 11:21 PM Hi Lv, On Fri, Jun 19, 2015 at 5:38 AM, Lv Zheng lv.zh...@intel.com wrote: ACPICA commit 7aa598d711644ab0de5f70ad88f1e2de253115e4 The root cause

RE: [PATCH 2/6] ACPI / EC: Cleanup _Qxx evaluation work item.

of this patchset after testing. Thanks and best regards -Lv > From: Zheng, Lv > Sent: Monday, June 08, 2015 1:28 PM > > The _Qxx evaluation work item can be eliminated and _Qxx can be evaluated > right in the same work item as the QR_EC transaction. This patch cleans up > t

RE: [PATCH 2/6] ACPI / EC: Cleanup _Qxx evaluation work item.

of this patchset after testing. Thanks and best regards -Lv From: Zheng, Lv Sent: Monday, June 08, 2015 1:28 PM The _Qxx evaluation work item can be eliminated and _Qxx can be evaluated right in the same work item as the QR_EC transaction. This patch cleans up the code to achieve this. Originally

RE: 3 EC issues

Hi, I just made a freak change to let reporters to try. https://bugzilla.kernel.org/attachment.cgi?id=178271=diff I'll report back after seeing their test results. Thanks and best regards -Lv > From: Zheng, Lv > Sent: Wednesday, May 27, 2015 1:57 PM > > Hi, > > Let

RE: 3 EC issues

Hi, I just made a freak change to let reporters to try. https://bugzilla.kernel.org/attachment.cgi?id=178271action=diff I'll report back after seeing their test results. Thanks and best regards -Lv From: Zheng, Lv Sent: Wednesday, May 27, 2015 1:57 PM Hi, Let me Cc intel power

RE: 3 EC issues

May 23, 2015 8:32 AM > > Len, > > It appears that we need to know what the Windows EC driver expects from > the firmware. > > Who's the first point of contact for that? > > Rafael > > > On 5/22/2015 9:33 AM, Zheng, Lv wrote: > > Hi, Bob and Raf

RE: 3 EC issues

to know what the Windows EC driver expects from the firmware. Who's the first point of contact for that? Rafael On 5/22/2015 9:33 AM, Zheng, Lv wrote: Hi, Bob and Rafael I have 3 ACPI bugs related to the EC event handling mechanism. https://bugzilla.kernel.org/show_bug.cgi?id=98111

RE: [PATCH 12/19] ACPICA: ACPI 6.0: Add changes for MADT table.

Hi, > From: Hanjun Guo [mailto:hanjun@linaro.org] > Sent: Thursday, May 21, 2015 10:36 PM > > Hi Lv, > > On 2015年05月21日 10:31, Lv Zheng wrote: > > From: Bob Moore > > > > ACPICA commit 02cbb41232bccf7a91967140cab95d5f48291f21 > > > > New subtable type. Some additions to existing subtables.

RE: [PATCH 12/19] ACPICA: ACPI 6.0: Add changes for MADT table.

Hi, From: Hanjun Guo [mailto:hanjun@linaro.org] Sent: Thursday, May 21, 2015 10:36 PM Hi Lv, On 2015年05月21日 10:31, Lv Zheng wrote: From: Bob Moore robert.mo...@intel.com ACPICA commit 02cbb41232bccf7a91967140cab95d5f48291f21 New subtable type. Some additions to existing

RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader

Hi, > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Thursday, April 30, 2015 4:49 PM > > On Thu, Apr 30, 2015 at 08:05:12AM +0000, Zheng, Lv wrote: > > Are there any such data around the SC and LL (MIPS)? > > What, you can't search the internet yourself? I me

RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader

Hi, From: Borislav Petkov [mailto:b...@alien8.de] Sent: Thursday, April 30, 2015 4:49 PM On Thu, Apr 30, 2015 at 08:05:12AM +, Zheng, Lv wrote: Are there any such data around the SC and LL (MIPS)? What, you can't search the internet yourself? I mean if LL can do what you exactly

RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader

Hi, > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Wednesday, April 29, 2015 4:14 PM > Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader > > On Wed, Apr 29, 2015 at 12:49:59AM +, Zheng, Lv wrote: > > > > We absolutely want to use ato

RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader

Hi, From: Borislav Petkov [mailto:b...@alien8.de] Sent: Wednesday, April 29, 2015 4:14 PM Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader On Wed, Apr 29, 2015 at 12:49:59AM +, Zheng, Lv wrote: We absolutely want to use atomic_add_unless() because we get

RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader

Hi, > From: Zheng, Lv > Sent: Wednesday, April 29, 2015 8:25 AM > Subject: RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader > > Hi, > > > From: Borislav Petkov [mailto:b...@alien8.de] > > Sent: Tuesday, April 28, 2015 9:59 PM > > Subject

RE: [PATCH] ACPICA: remove duplicate u8 typedef

Hi, > From: Olaf Hering [mailto:o...@aepfle.de] > Sent: Tuesday, April 28, 2015 10:54 PM > Subject: [PATCH] ACPICA: remove duplicate u8 typedef > > During commit e252652fb2664d42de19f933aa3688bbc470de3f ("ACPICA: > acpidump: Remove integer types translation protection.") two 'unsigned > char'

RE: [PATCH] ACPICA: remove duplicate u8 typedef

Hi, > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Wednesday, April 29, 2015 8:44 AM > Subject: Re: [PATCH] ACPICA: remove duplicate u8 typedef > > On Tuesday, April 28, 2015 04:54:04 PM Olaf Hering wrote: > > During commit e252652fb2664d42de19f933aa3688bbc470de3f ("ACPICA: > >

RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader

Hi, > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Tuesday, April 28, 2015 9:59 PM > Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader > > On Tue, Apr 28, 2015 at 01:38:41PM +, Zheng, Lv wrote: > > > - raw_spin_lock(_nmi_lock); > &

RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader

Hi, I was talking about this patch. > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Friday, March 27, 2015 5:23 PM > Subject: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader > > From: Jiri Kosina > > Since GHES sources are global, we theoretically need only a single CPU >

RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader

Hi, From: Borislav Petkov [mailto:b...@alien8.de] Sent: Tuesday, April 28, 2015 9:59 PM Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader On Tue, Apr 28, 2015 at 01:38:41PM +, Zheng, Lv wrote: - raw_spin_lock(ghes_nmi_lock); + if (!atomic_add_unless

RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader

Hi, From: Zheng, Lv Sent: Wednesday, April 29, 2015 8:25 AM Subject: RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader Hi, From: Borislav Petkov [mailto:b...@alien8.de] Sent: Tuesday, April 28, 2015 9:59 PM Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have

RE: [PATCH] ACPICA: remove duplicate u8 typedef

Hi, From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Wednesday, April 29, 2015 8:44 AM Subject: Re: [PATCH] ACPICA: remove duplicate u8 typedef On Tuesday, April 28, 2015 04:54:04 PM Olaf Hering wrote: During commit e252652fb2664d42de19f933aa3688bbc470de3f (ACPICA: acpidump:

RE: [PATCH] ACPICA: remove duplicate u8 typedef

Hi, From: Olaf Hering [mailto:o...@aepfle.de] Sent: Tuesday, April 28, 2015 10:54 PM Subject: [PATCH] ACPICA: remove duplicate u8 typedef During commit e252652fb2664d42de19f933aa3688bbc470de3f (ACPICA: acpidump: Remove integer types translation protection.) two 'unsigned char' types got

RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader

Hi, I was talking about this patch. From: Borislav Petkov [mailto:b...@alien8.de] Sent: Friday, March 27, 2015 5:23 PM Subject: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader From: Jiri Kosina jkos...@suse.cz Since GHES sources are global, we theoretically need only a

<    1   2   3   4   5   6   7   8   9   10   >