Hi,
> From: Zheng, Lv
> Sent: Tuesday, April 28, 2015 8:44 AM
>
> Hi,
>
> > From: Borislav Petkov [mailto:b...@alien8.de]
> > Sent: Monday, April 27, 2015 4:47 PM
> >
> > On Mon, Apr 27, 2015 at 03:16:00AM +, Zheng, Lv wrote:
> > > > @@ -
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Monday, April 27, 2015 4:47 PM
>
> On Mon, Apr 27, 2015 at 03:16:00AM +0000, Zheng, Lv wrote:
> > > @@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned int cmd, struct
> > > pt_regs *regs)
> > &g
Hi,
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Monday, April 27, 2015 4:47 PM
On Mon, Apr 27, 2015 at 03:16:00AM +, Zheng, Lv wrote:
@@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned int cmd, struct
pt_regs *regs)
struct ghes *ghes;
int sev, ret = NMI_DONE
Hi,
From: Zheng, Lv
Sent: Tuesday, April 28, 2015 8:44 AM
Hi,
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Monday, April 27, 2015 4:47 PM
On Mon, Apr 27, 2015 at 03:16:00AM +, Zheng, Lv wrote:
@@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned int cmd, struct
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Friday, March 27, 2015 5:23 PM
>
> From: Jiri Kosina
>
> Since GHES sources are global, we theoretically need only a single CPU
> reading them per NMI instead of a thundering herd of CPUs waiting on a
> spinlock in NMI context for no
Hi,
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Friday, March 27, 2015 5:23 PM
From: Jiri Kosina jkos...@suse.cz
Since GHES sources are global, we theoretically need only a single CPU
reading them per NMI instead of a thundering herd of CPUs waiting on a
spinlock in NMI context
Before back porting this to ACPICA, let me ask one simple question.
According to the spec, the _CLS is optional and PCI specific.
So why should we implement it in ACPICA core not OSPM specific modules?
If this need to be implemented in ACPICA, then what about the following device
identification
Before back porting this to ACPICA, let me ask one simple question.
According to the spec, the _CLS is optional and PCI specific.
So why should we implement it in ACPICA core not OSPM specific modules?
If this need to be implemented in ACPICA, then what about the following device
identification
Hi,
Thanks for noticing this.
> From: Andreas Ruprecht [mailto:andreas.rupre...@fau.de]
> Sent: Sunday, April 12, 2015 8:19 PM
>
> In commit 9d24622ced32 ("ACPI / IBFT: Fix incorrect
> inclusion in iSCSI boot firmware module"), the dependencies for
> CONFIG_ISCSI_IBFT_FIND were changed to also
Hi,
Thanks for noticing this.
From: Andreas Ruprecht [mailto:andreas.rupre...@fau.de]
Sent: Sunday, April 12, 2015 8:19 PM
In commit 9d24622ced32 (ACPI / IBFT: Fix incorrect acpi/acpi.h
inclusion in iSCSI boot firmware module), the dependencies for
CONFIG_ISCSI_IBFT_FIND were changed to
Hi, Gabriele
I couldn't find this in my mail box, but saw it in the spinics.net.
For EC query, there is no spec definitions around its behavior.
Some EC firmware will have events queued (like edge triggering) while the
others will keeps on reporting events when a condition is set (like level
Hi, Gabriele
I couldn't find this in my mail box, but saw it in the spinics.net.
For EC query, there is no spec definitions around its behavior.
Some EC firmware will have events queued (like edge triggering) while the
others will keeps on reporting events when a condition is set (like level
Hi,
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Thursday, February 26, 2015 6:56 AM
>
> On Wednesday, February 25, 2015 03:01:08 PM Scot Doyle wrote:
> > On Wed, 25 Feb 2015, Zheng, Lv wrote:
> > ...
> > > > I was using "+"/&quo
Hi,
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Thursday, February 26, 2015 6:56 AM
On Wednesday, February 25, 2015 03:01:08 PM Scot Doyle wrote:
On Wed, 25 Feb 2015, Zheng, Lv wrote:
...
I was using +/#/* to filter different EC log entries
which makes
Hi,
> From: Zheng, Lv
> Sent: Wednesday, February 25, 2015 4:42 PM
>
> Hi,
>
> > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > Sent: Wednesday, February 18, 2015 2:19 PM
> > To: Scot Doyle
> > Cc: Zheng, Lv; linux-a...@vger.kernel.org; linux
Hi,
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, February 18, 2015 2:19 PM
> To: Scot Doyle
> Cc: Zheng, Lv; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ACPI / EC: Remove non-standard log emphasis
>
> On Sunday,
Hi,
From: Zheng, Lv
Sent: Wednesday, February 25, 2015 4:42 PM
Hi,
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Wednesday, February 18, 2015 2:19 PM
To: Scot Doyle
Cc: Zheng, Lv; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ACPI / EC
Hi,
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Wednesday, February 18, 2015 2:19 PM
To: Scot Doyle
Cc: Zheng, Lv; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ACPI / EC: Remove non-standard log emphasis
On Sunday, February 15, 2015 07:43:08
Hi,
> From: Wysocki, Rafael J
> Sent: Thursday, February 12, 2015 9:18 AM
>
> On 2/9/2015 3:23 AM, Zheng, Lv wrote:
> > Hi, Rafael
> >
> >> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> >> Sent: Friday, February 06, 2015 9:27 AM
> >>
>
Hi,
From: Wysocki, Rafael J
Sent: Thursday, February 12, 2015 9:18 AM
On 2/9/2015 3:23 AM, Zheng, Lv wrote:
Hi, Rafael
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Friday, February 06, 2015 9:27 AM
On Friday, February 06, 2015 08:57:37 AM Lv Zheng wrote
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Friday, February 06, 2015 9:27 AM
>
> On Friday, February 06, 2015 08:57:37 AM Lv Zheng wrote:
> > This patchset contains 3 cleanups related to the EC driver:
> > 1. Command flushing (command grace period)
> >This
Hi, Rafael
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Friday, February 06, 2015 9:27 AM
On Friday, February 06, 2015 08:57:37 AM Lv Zheng wrote:
This patchset contains 3 cleanups related to the EC driver:
1. Command flushing (command grace period)
This patchset
Hi, Octavian
> From: Octavian Purdila [mailto:octavian.purd...@intel.com]
> Sent: Saturday, January 17, 2015 2:03 PM
>
> On Fri, Jan 16, 2015 at 11:44 AM, Zheng, Lv wrote:
> > Hi, Octavian
> >
>
> Hi Lv,
>
> > I noticed there are 2 patches you've sent to
Hi, Gerry
> From: Jiang Liu [mailto:jiang@linux.intel.com]
> Sent: Thursday, January 22, 2015 10:58 AM
>
> On 2015/1/22 10:32, Zheng, Lv wrote:
> > Hi, Thomas and Jiang
> >
> >> From: Jiang Liu [mailto:jiang@linux.intel.com]
> >> Sent: Thursday
Hi, Thomas and Jiang
> From: Jiang Liu [mailto:jiang@linux.intel.com]
> Sent: Thursday, January 08, 2015 10:33 AM
>
> From: Thomas Gleixner
>
> address_space64 and ext_address_space64 share substracts just at
> different offsets. To unify the parsing functions implement the two
> structs
Hi, Octavian
From: Octavian Purdila [mailto:octavian.purd...@intel.com]
Sent: Saturday, January 17, 2015 2:03 PM
On Fri, Jan 16, 2015 at 11:44 AM, Zheng, Lv lv.zh...@intel.com wrote:
Hi, Octavian
Hi Lv,
I noticed there are 2 patches you've sent to the community
Hi, Thomas and Jiang
From: Jiang Liu [mailto:jiang@linux.intel.com]
Sent: Thursday, January 08, 2015 10:33 AM
From: Thomas Gleixner t...@linutronix.de
address_space64 and ext_address_space64 share substracts just at
different offsets. To unify the parsing functions implement the two
Hi, Gerry
From: Jiang Liu [mailto:jiang@linux.intel.com]
Sent: Thursday, January 22, 2015 10:58 AM
On 2015/1/22 10:32, Zheng, Lv wrote:
Hi, Thomas and Jiang
From: Jiang Liu [mailto:jiang@linux.intel.com]
Sent: Thursday, January 08, 2015 10:33 AM
From: Thomas Gleixner t
Hi, Octavian
I noticed there are 2 patches you've sent to the community.
But unfortunately I didn't find them in my mailbox.
Let me comment you here.
https://patchwork.kernel.org/patch/5501621/
This patch seem to be correct.
But Rafael should merge it directly via Linux because
Hi, Octavian
I noticed there are 2 patches you've sent to the community.
But unfortunately I didn't find them in my mailbox.
Let me comment you here.
https://patchwork.kernel.org/patch/5501621/
This patch seem to be correct.
But Rafael should merge it directly via Linux because
uch useless "#ifdef".
A source file should only contain the self contained logics in it without
considering the users.
Thanks and best regards
-Lv
> -Original Message-
> From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
> Sent: Wednesday, Januar
Hi,
> From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
> Sent: Thursday, January 15, 2015 6:50 AM
>
> 2015-01-14 9:55 GMT+01:00 Zheng, Lv :
> > Hi, Rickard
> >
> > The functions below seem already marked by "ACPI_ASL_COMPILER ||
y 04, 2015 11:23 PM
> To: Moore, Robert; Zheng, Lv
> Cc: Rickard Strandqvist; Wysocki, Rafael J; Len Brown;
> linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] acpica: utpredef: Remove some unused functions
>
> Removes some
ist [mailto:rickard_strandqv...@spectrumdigital.se]
> Sent: Wednesday, January 14, 2015 2:49 AM
> To: Moore, Robert; Zheng, Lv
> Cc: Rickard Strandqvist; Wysocki, Rafael J; Len Brown;
> linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] ACPICA: tbinstal: Remo
Hi,
From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
Sent: Thursday, January 15, 2015 6:50 AM
2015-01-14 9:55 GMT+01:00 Zheng, Lv lv.zh...@intel.com:
Hi, Rickard
The functions below seem already marked by ACPI_ASL_COMPILER ||
ACPI_HELP_APP.
How did you
should only contain the self contained logics in it without
considering the users.
Thanks and best regards
-Lv
-Original Message-
From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
Sent: Wednesday, January 14, 2015 2:44 AM
To: Moore, Robert; Zheng, Lv
Cc: Rickard
[mailto:rickard_strandqv...@spectrumdigital.se]
Sent: Wednesday, January 14, 2015 2:49 AM
To: Moore, Robert; Zheng, Lv
Cc: Rickard Strandqvist; Wysocki, Rafael J; Len Brown;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
Subject: [PATCH] ACPICA: tbinstal: Remove unused function
Remove
To: Moore, Robert; Zheng, Lv
Cc: Rickard Strandqvist; Wysocki, Rafael J; Len Brown;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
Subject: [PATCH] acpica: utpredef: Remove some unused functions
Removes some functions that are not used anywhere
this is not the motivation that has caused you to try to remove the
__DATE__ usages.
Thanks and best regards
-Lv
> From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv
> Sent: Tuesday, January 13, 2015 10:33 AM
>
> Hi,
>
> I've added this patch into the 20150
; Sent: Wednesday, January 07, 2015 3:36 AM
>
> On Tue, Jan 06, 2015 at 12:30:05AM +0000, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
> > > Sent: Monday, January 05, 2015 6:27 PM
> > >
> > &g
; Sent: Tuesday, January 06, 2015 7:30 AM
>
> On Monday, January 05, 2015 08:39:37 AM Zheng, Lv wrote:
> > Hi, Richard
> >
> > > From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
> > > Sent: Saturday, January 03, 20
: Wednesday, January 07, 2015 3:36 AM
On Tue, Jan 06, 2015 at 12:30:05AM +, Zheng, Lv wrote:
Hi,
From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
Sent: Monday, January 05, 2015 6:27 PM
On Mon, Jan 05 2015, Zheng, Lv lv.zh...@intel.com wrote:
Hi,
From: Rasmus
, January 06, 2015 7:30 AM
On Monday, January 05, 2015 08:39:37 AM Zheng, Lv wrote:
Hi, Richard
From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
Sent: Saturday, January 03, 2015 5:01 AM
Remove the function acpi_ut_create_pkg_state_and_push
this is not the motivation that has caused you to try to remove the
__DATE__ usages.
Thanks and best regards
-Lv
From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv
Sent: Tuesday, January 13, 2015 10:33 AM
Hi,
I've added this patch into the 201501 ACPICA materials for review
Hi,
> From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
> Sent: Monday, January 05, 2015 6:27 PM
>
> On Mon, Jan 05 2015, "Zheng, Lv" wrote:
>
> > Hi,
> >
> >> From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
> >> Sen
Hi,
> From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
> Sent: Friday, December 12, 2014 6:51 PM
> To: Zheng, Lv
> Cc: Rasmus Villemoes; linux-a...@vger.kernel.org; de...@acpica.org;
> linux-kernel@vger.kernel.org
> Subject: [PATCH 3/3] ACPICA: Remove use of __DATE__ ma
Hi, Richard
> From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
> Sent: Saturday, January 03, 2015 5:01 AM
>
> Remove the function acpi_ut_create_pkg_state_and_push() that is not used
> anywhere.
>
> This was partially found by using a static code analysis program
Hi, Rickard
> From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
> Sent: Friday, January 02, 2015 1:16 AM
>
> Remove the function acpi_ut_is_aml_table() that is not used anywhere.
This function is used by the ACPICA debugger and disassembler.
The ACPICA release process
Hi,
From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
Sent: Friday, December 12, 2014 6:51 PM
To: Zheng, Lv
Cc: Rasmus Villemoes; linux-a...@vger.kernel.org; de...@acpica.org;
linux-kernel@vger.kernel.org
Subject: [PATCH 3/3] ACPICA: Remove use of __DATE__ macro
The macro
Hi, Rickard
From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
Sent: Friday, January 02, 2015 1:16 AM
Remove the function acpi_ut_is_aml_table() that is not used anywhere.
This function is used by the ACPICA debugger and disassembler.
The ACPICA release process has
Hi, Richard
From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
Sent: Saturday, January 03, 2015 5:01 AM
Remove the function acpi_ut_create_pkg_state_and_push() that is not used
anywhere.
This was partially found by using a static code analysis program called
Hi,
From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
Sent: Monday, January 05, 2015 6:27 PM
On Mon, Jan 05 2015, Zheng, Lv lv.zh...@intel.com wrote:
Hi,
From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
Sent: Friday, December 12, 2014 6:51 PM
To: Zheng, Lv
Cc
Hi,
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Monday, November 24, 2014 11:20 PM
> Lv
> Subject: Re: [PATCH v3 updated 3/3] ACPI / PMIC: AXP288: support virtual GPIO
> in ACPI table
>
> On Monday, November 24, 2014 05:32:33 PM Aaron Lu wrote:
> > On 11/24/2014 09:06 AM,
Hi,
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Monday, November 24, 2014 11:20 PM
Lv
Subject: Re: [PATCH v3 updated 3/3] ACPI / PMIC: AXP288: support virtual GPIO
in ACPI table
On Monday, November 24, 2014 05:32:33 PM Aaron Lu wrote:
On 11/24/2014 09:06 AM, Rafael J.
://bugs.acpica.org/show_bug.cgi?id=1100
Thanks and best regards
-Lv
> From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
> Sent: Friday, November 21, 2014 8:41 PM
>
> On Fri, Nov 21, 2014 at 01:05:40AM +0000, Zheng, Lv wrote:
> > Hi, Kirill
> >
> > Please help to
://bugs.acpica.org/show_bug.cgi?id=1100
Thanks and best regards
-Lv
From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
Sent: Friday, November 21, 2014 8:41 PM
On Fri, Nov 21, 2014 at 01:05:40AM +, Zheng, Lv wrote:
Hi, Kirill
Please help to check again to use the updated patch
This result convinces me that this might only be a theoretical dead lock for
now.
So finally we won't need this in order to eliminate this warning.
Thanks and best regards
-Lv
> From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
> Sent: Friday, November 21, 2014 6:16 AM
> To: Zheng
Hi, All
It's my fault.
I didn't add ACPI_GPE_HANDLER_RAW flag in ec.c to enable this fix.
Sorry for the noise.
Let me post the updated [RFC PATCH 2] for you to confirm.
Thanks
-Lv
> From: Zheng, Lv
> Sent: Friday, November 21, 2014 8:43 AM
>
> Hi, Shutemov
>
> > Fro
Hi, Shutemov
> From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
> Sent: Friday, November 21, 2014 5:34 AM
>
> On Thu, Nov 20, 2014 at 02:20:53AM +0000, Zheng, Lv wrote:
> > Since you have environment to trigger this.
> > Could you also help to check if the fix can
Hi, Shutemov
From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
Sent: Friday, November 21, 2014 5:34 AM
On Thu, Nov 20, 2014 at 02:20:53AM +, Zheng, Lv wrote:
Since you have environment to trigger this.
Could you also help to check if the fix can work?
I've just sent them
Hi, All
It's my fault.
I didn't add ACPI_GPE_HANDLER_RAW flag in ec.c to enable this fix.
Sorry for the noise.
Let me post the updated [RFC PATCH 2] for you to confirm.
Thanks
-Lv
From: Zheng, Lv
Sent: Friday, November 21, 2014 8:43 AM
Hi, Shutemov
From: Kirill A. Shutemov [mailto:kir
This result convinces me that this might only be a theoretical dead lock for
now.
So finally we won't need this in order to eliminate this warning.
Thanks and best regards
-Lv
From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
Sent: Friday, November 21, 2014 6:16 AM
To: Zheng, Lv
Cc: Lv
Hi, Kirill
Could also help to confirm if this patch can also fix the issue.
Please help to validate the 2 fix patchsets separately.
Thanks in advance.
Best regards
-Lv
> From: Zheng, Lv
> Sent: Thursday, November 20, 2014 2:45 PM
>
> On some platforms, GPE is not disabled by d
5, 2014 at 02:52:36AM +, Zheng, Lv wrote:
> >
> > [cut]
> >
> > >
> > > Here's lockdep warning I see on -next:
> >
> > Is patch [1/6] sufficient to trigger this or do you need all [1-4/6]?
>
> I only saw it on -next. I've tried to apply p
ocki
> Cc: Zheng, Lv; Wysocki, Rafael J; Brown, Len; Lv Zheng;
> linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org
> Subject: Re: [PATCH 1/6] ACPI/EC: Introduce STARTED/STOPPED flags to replace
> BLOCKED flag.
>
> On Tue, Nov 18, 2014 at 10:20:11PM +0100, Rafael J. Wy
should be merged first.
IMO, the GPE dead lock fix is the most basic one.
Thanks and best regards
-Lv
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, November 19, 2014 5:20 AM
> To: Kirill A. Shutemov
> Cc: Zheng, Lv; Wysocki, Rafael J; Brown, Len; Lv Zheng;
&g
should be merged first.
IMO, the GPE dead lock fix is the most basic one.
Thanks and best regards
-Lv
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Wednesday, November 19, 2014 5:20 AM
To: Kirill A. Shutemov
Cc: Zheng, Lv; Wysocki, Rafael J; Brown, Len; Lv Zheng;
linux-kernel
: Zheng, Lv; Wysocki, Rafael J; Brown, Len; Lv Zheng;
linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org
Subject: Re: [PATCH 1/6] ACPI/EC: Introduce STARTED/STOPPED flags to replace
BLOCKED flag.
On Tue, Nov 18, 2014 at 10:20:11PM +0100, Rafael J. Wysocki wrote:
On Tuesday, November 18
Hi,
From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
Sent: Wednesday, November 19, 2014 8:16 PM
On Tue, Nov 18, 2014 at 10:20:11PM +0100, Rafael J. Wysocki wrote:
On Tuesday, November 18, 2014 03:23:28 PM Kirill A. Shutemov wrote:
On Wed, Nov 05, 2014 at 02:52:36AM +, Zheng
Hi, Kirill
Could also help to confirm if this patch can also fix the issue.
Please help to validate the 2 fix patchsets separately.
Thanks in advance.
Best regards
-Lv
From: Zheng, Lv
Sent: Thursday, November 20, 2014 2:45 PM
On some platforms, GPE is not disabled by default after ACPI
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Friday, November 14, 2014 6:38 AM
>
> On Thursday, November 13, 2014 02:52:03 AM Zheng, Lv wrote:
> > Hi, Rafael
> >
> > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > >
Hi, Rafael
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Friday, November 14, 2014 6:38 AM
On Thursday, November 13, 2014 02:52:03 AM Zheng, Lv wrote:
Hi, Rafael
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Thursday, November 13, 2014 10:59 AM
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Thursday, November 13, 2014 10:59 AM
>
> On Thursday, November 13, 2014 02:31:08 AM Zheng, Lv wrote:
> > Hi, Rafael
> >
> > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > &g
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, November 12, 2014 9:17 AM
>
> On Monday, November 03, 2014 01:16:37 PM Lv Zheng wrote:
> > There is wait code in the QR_SC command processing, which makes it not
> > suitable to be put into a work queue item (see
Hi, Rafael
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Wednesday, November 12, 2014 9:17 AM
On Monday, November 03, 2014 01:16:37 PM Lv Zheng wrote:
There is wait code in the QR_SC command processing, which makes it not
suitable to be put into a work queue item (see bug
Hi, Rafael
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Thursday, November 13, 2014 10:59 AM
On Thursday, November 13, 2014 02:31:08 AM Zheng, Lv wrote:
Hi, Rafael
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Wednesday, November 12, 2014 9:17 AM
[cut
e to
find a solution.
> From: Zheng, Lv
> Sent: Monday, November 03, 2014 1:16 PM
>
> By using the 2 flags, we can indicate an inter-mediate state where the
> current transactions should be completed while the new transactions should
> be dropped.
>
> The comparison of the o
a solution.
From: Zheng, Lv
Sent: Monday, November 03, 2014 1:16 PM
By using the 2 flags, we can indicate an inter-mediate state where the
current transactions should be completed while the new transactions should
be dropped.
The comparison of the old flag and the new flags:
Old
There are reasons for why RCU is used here.
Using spinlock here will break specific
acpi_os_read_memory()/acpi_os_write_memory() users.
So this patchset is not correct, please ignore.
Thanks
-Lv
> From: Zheng, Lv
> Sent: Thursday, October 23, 2014 10:12 AM
>
> It
There are reasons for why RCU is used here.
Using spinlock here will break specific
acpi_os_read_memory()/acpi_os_write_memory() users.
So this patchset is not correct, please ignore.
Thanks
-Lv
From: Zheng, Lv
Sent: Thursday, October 23, 2014 10:12 AM
It is reported
Hi,
Thanks for letting me know.
Though IMO the ACER behavior is not ACPI spec compliant, but following it still
shouldn't break the others.
Because it just requires EC firmware to always flag SCI_EVT when there is an
event queued up.
I couldn't see a special reason that a correct EC firmware
Hi,
Thanks for letting me know.
Though IMO the ACER behavior is not ACPI spec compliant, but following it still
shouldn't break the others.
Because it just requires EC firmware to always flag SCI_EVT when there is an
event queued up.
I couldn't see a special reason that a correct EC firmware
Hi,
> From: Grant Likely [mailto:glik...@secretlab.ca] On Behalf Of Grant Likely
> Sent: Thursday, September 11, 2014 5:52 AM
>
> On Wed, 10 Sep 2014 13:33:52 +0100, Catalin Marinas
> wrote:
> > On Wed, Sep 10, 2014 at 12:13:51PM +0100, Hanjun Guo wrote:
> > > On 2014/9/10 3:06, Jon Masters
Hi,
From: Grant Likely [mailto:glik...@secretlab.ca] On Behalf Of Grant Likely
Sent: Thursday, September 11, 2014 5:52 AM
On Wed, 10 Sep 2014 13:33:52 +0100, Catalin Marinas catalin.mari...@arm.com
wrote:
On Wed, Sep 10, 2014 at 12:13:51PM +0100, Hanjun Guo wrote:
On 2014/9/10 3:06,
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Dave Young
> Sent: Tuesday, August 26, 2014 5:07 PM
>
> 3.16 kernel boot fail with earlyprintk=efi, it keeps scrolling at the
> bottom line of screen.
>
> Bisected, the first bad commit is
Hi,
From: linux-acpi-ow...@vger.kernel.org
[mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Dave Young
Sent: Tuesday, August 26, 2014 5:07 PM
3.16 kernel boot fail with earlyprintk=efi, it keeps scrolling at the
bottom line of screen.
Bisected, the first bad commit is below:
Hi,
> From: Dave Young [mailto:dyo...@redhat.com]
> Sent: Monday, August 25, 2014 2:07 PM
> To: Matt Fleming
> Cc: Zheng, Lv; Fleming, Matt; linux-...@vger.kernel.org;
> linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; de...@acpica.org;
> l...@kernel.org; Wysock
Hi,
From: Dave Young [mailto:dyo...@redhat.com]
Sent: Monday, August 25, 2014 2:07 PM
To: Matt Fleming
Cc: Zheng, Lv; Fleming, Matt; linux-...@vger.kernel.org;
linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; de...@acpica.org;
l...@kernel.org; Wysocki, Rafael J; Moore, Robert
defined in arch/x86/include/asm/fixmap.h.
What do you think of this?
Thanks and best regards
-Lv
> From: Zheng, Lv
> Sent: Friday, August 22, 2014 9:43 AM
>
> Hi,
>
> There is only limited entries in the x86 early mapping which is implemented
> by the FIXMAP.
> So t
Hi,
There is only limited entries in the x86 early mapping which is implemented by
the FIXMAP.
So this means for all __init call invoked for x86, if there was a early mapping
in it, it should be unmapped before exiting the __init call.
Using this rule, all __init call implementers can make
: Wysocki, Rafael J
Sent: Friday, August 22, 2014 3:55 AM
To: Zheng, Lv; Brown, Len
Cc: Lv Zheng; linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org
Subject: RE: [PATCH 2/2] ACPI/EC: Add support to disallow QR_EC to be issued
before completing the previous QR_EC.
Looks OK to me.
Rafael
: Wysocki, Rafael J
Sent: Friday, August 22, 2014 3:55 AM
To: Zheng, Lv; Brown, Len
Cc: Lv Zheng; linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org
Subject: RE: [PATCH 2/2] ACPI/EC: Add support to disallow QR_EC to be issued
before completing the previous QR_EC.
Looks OK to me.
Rafael
Hi,
There is only limited entries in the x86 early mapping which is implemented by
the FIXMAP.
So this means for all __init call invoked for x86, if there was a early mapping
in it, it should be unmapped before exiting the __init call.
Using this rule, all __init call implementers can make
defined in arch/x86/include/asm/fixmap.h.
What do you think of this?
Thanks and best regards
-Lv
From: Zheng, Lv
Sent: Friday, August 22, 2014 9:43 AM
Hi,
There is only limited entries in the x86 early mapping which is implemented
by the FIXMAP.
So this means for all __init call
Hi,
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, July 23, 2014 6:15 AM
>
> On Tuesday, July 22, 2014 01:25:00 AM Zheng, Lv wrote:
> > Hi, Rafael
> >
> > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> >
Hi,
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Wednesday, July 23, 2014 6:15 AM
On Tuesday, July 22, 2014 01:25:00 AM Zheng, Lv wrote:
Hi, Rafael
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Tuesday, July 22, 2014 9:12 AM
On Monday, July 21, 2014
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Tuesday, July 22, 2014 9:12 AM
>
> On Monday, July 21, 2014 02:04:51 PM Lv Zheng wrote:
> > Note that this patchset is very stable now, it is sent as RFC because it
> > depends on an ACPICA GPE enhancement series which
Hi, Rafael
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Tuesday, July 22, 2014 9:12 AM
On Monday, July 21, 2014 02:04:51 PM Lv Zheng wrote:
Note that this patchset is very stable now, it is sent as RFC because it
depends on an ACPICA GPE enhancement series which might be
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Sunday, July 20, 2014 7:46 AM
> To: Zheng, Lv
>
> On Wednesday, July 16, 2014 04:58:00 PM Lv Zheng wrote:
> > This patch adds default 64-bit mathematics in aclinux.h using do_div(). As
> > do_div(
Hi, Rafael
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Sunday, July 20, 2014 7:46 AM
To: Zheng, Lv
On Wednesday, July 16, 2014 04:58:00 PM Lv Zheng wrote:
This patch adds default 64-bit mathematics in aclinux.h using do_div(). As
do_div() can be used for all Linux
601 - 700 of 918 matches
Mail list logo
