x PM list; ACPI Devel Maling List; Zhang, Rui;
> Svahn, Kai; Mika Westerberg; Huang, Ying; Lan, Tianyu; Zheng, Lv; Lu, Aaron;
> Grant Likely
> Subject: [PATCH 2/2] platform / ACPI: Attach/detach ACPI PM during
> probe/remove/shutdown
>
> From: Rafael J. Wysocki
>
> Drive
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Mika Westerberg
> Sent: Friday, September 13, 2013 11:15 PM
>
> GPIO operation regions is a new feature introduced in ACPI 5.0
> specification. In practise it means that now ASL code can toggle GPIOs
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Sent: Sunday, September 15, 2013 2:52 PM
>
> On Sat, Sep 14, 2013 at 12:10:37AM +0000, Zheng, Lv wrote:
> > Is it possible to install the handler for ACPI_ROOT_OBJECT?
> > Can it be achieved by imple
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng, Lv
> Sent: Monday, September 16, 2013 8:47 AM
>
> > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> > Sent: Sunday, September 15, 2013 2:52 PM
> &g
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Sent: Monday, September 16, 2013 4:11 PM
>
> On Mon, Sep 16, 2013 at 01:21:53AM +0000, Zheng, Lv wrote:
> > > A pseudo device may be created to access the GPIO operation region fields
> > > provided
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Sent: Tuesday, September 17, 2013 4:37 PM
>
> On Mon, Sep 16, 2013 at 11:35:56PM +0000, Zheng, Lv wrote:
> > > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> > > Sent: Mond
> go ahead and take the series in tip 3.8, Peter, thanks.
>
> I looked over this series a while back and my feedback was that it should be
> disabled by default and enabled by bootparam -- like other earlyprink -- else
> an
> issue here would render a system un-bootable. I see that LV has addres
> > Signed-off-by: Lv Zheng
> > Reviewed-by: Len Brown
> > Reviewed-by: Rui Zhang
> > Reviewed-by: Ying Huang
> > Reviewed-by: Konrad Rzeszutek Wilk
> Please don't include that unless I (or other folks looking at your code) say
> explicitly 'Acked' or 'Reviewed-by'
ACK.
I'll remove these name
> > earlyprintk=acpi
> .. or earlyprintk=mrst
> ?
ACK.
The two launchers are all workable for MID_SPI. I'll add more comments and
resend this patch. Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
> > +int __init acpi_early_console_keep(struct acpi_debug_port *info)
>
> Why not make it 'bool' like the other (acpi_early_console_enabled)?
NAK.
"keep" is "int" in "setup_early_printk".
Best regards/Lv Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
> > +#ifdef CONFIG_EARLY_PRINTK_INTEL_MID_SPI
> > + if (info->port_type == ACPI_DBG2_SERIAL_PORT
> > + && info->port_subtype == ACPI_DBG2_INTEL_MID_SPI
> > + && info->register_count > 0) {
> Is it ever going to be zero?
NAK.
No register base definition (buggy BIOS?) is meaningless fo
> > +static __initdata DECLARE_BITMAP(acpi_early_flags,
> > +MAX_ACPI_DBG_PORTS*2);
It's OK since the keep bit will be derived by the real earlycon drivers in the
__acpi_early_console_start() which is an arch specific interface.
You can find this usage in the [PATCH v6 2/2].
> > + set_bit(port
r...@sisk.pl]
> Sent: Saturday, January 05, 2013 6:00 AM
> To: ACPI Devel Maling List
> Cc: LKML; Len Brown; Zheng, Lv; Huang, Ying
> Subject: [PATCH 1/6] ACPI / PM: Change the way power transitions to D3cold
> are carried out
>
> From: Rafael J. Wysocki
>
> During
Thanks for your efforts!
I wonder if it is possible to remove the argument - "u8 extended" and convert
"pm1a_control, pm1b_control" into some u8 values that are equivalent to
"acpi_gbl_sleep_type_a, acpi_gbl_sleep_type_b" in the legacy sleep path.
It can also simplify Xen codes.
As in ACPI spec
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
>
> On Friday, July 26, 2013 01:25:12 AM Zheng, Lv wrote:
> > > From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> > > Sent: Friday, July 26, 2013 6:26 A
> On Friday, July 26, 2013 10:01 PM Rafael J. Wysocki wrote:
> > On Friday, July 26, 2013 12:47:44 AM Zheng, Lv wrote:
> >
> > > On Friday, July 26, 2013 4:27 AM Rafael J. Wysocki wrote:
> > >
> > > On Tuesday, July 23, 2013 04:09:43 PM Lv Zheng wrote:
>
> On Friday, July 26, 2013 10:49 PM Rafael J. Wysocki wrote:
> > On Friday, July 26, 2013 01:54:00 AM Zheng, Lv wrote:
> > > On Friday, July 26, 2013 5:29 AM Rafael J. Wysocki wrote:
> > > On Tuesday, July 23, 2013 04:09:43 PM Lv Zheng wrote:
> > > > Thi
e all what we are talking about are the future, we can just live with the
current approaches.
We can find a way in the future when the conflicts do happen.
Thanks and best regards
-Lv
> On Saturday, July 27, 2013 2:04 AM konrad wilk
>> On 7/25/2013 10:51 PM, Zheng, Lv wrote:
>
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Greg KH
> Sent: Tuesday, July 23, 2013 10:54 PM
>
> On Tue, Jul 23, 2013 at 04:08:59PM +0800, Lv Zheng wrote:
> > This patch enhances sanity checks on message size to avoid potential
> > buffer overfl
> From: Zheng, Lv
> Sent: Wednesday, July 24, 2013 8:22 AM
>
> > From: linux-acpi-ow...@vger.kernel.org
> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Greg KH
> > Sent: Tuesday, July 23, 2013 10:54 PM
> >
> > On Tue, Jul 23, 2013 at 04:08:59PM
Hi,
Sorry for the delayed response.
> From: Ben Guthro [mailto:benjamin.gut...@citrix.com]
> Sent: Tuesday, July 02, 2013 7:43 PM
>
>
> On 07/02/2013 02:19 AM, Zheng, Lv wrote:
> > Thanks for your efforts!
> >
> > I wonder if it is possible to remove
ne point me to the overall description of this change and why it is
> being considered?
>
> Thanks,
> Bob
>
>
> > -Original Message-
> > From: Ben Guthro [mailto:benjamin.gut...@citrix.com]
> > Sent: Wednesday, July 24, 2013 6:23 AM
> > To: Mo
utek Wilk
> Sent: Thursday, July 25, 2013 12:32 AM
> To: Ben Guthro
> Cc: Moore, Robert; Zheng, Lv; Jan Beulich; Rafael J . Wysocki;
> linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org;
> xen-de...@lists.xen.org
> Subject: Re: [PATCH v3 1/3] acpi: Call acpi_os_prepare_slee
uch a bug.
On Wed, Jul 24, 2013 at 9:28 PM, Zheng, Lv wrote:
Let me just give an example to let you know the difficulties for ACPICA
developers to merge Xen's acpi_os_prepare_sleep.
The original logic in the acpi_hw_legacy_sleep is:
111 /* Get current value of PM1A control */
11
-stable according to the previous conversation.
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Thursday, July 25, 2013 7:38 AM
>
> On Tuesday, July 23, 2013 04:09:15 PM Lv Zheng wrote:
> > This patch fixes races caused by unprotected ACPI IPMI transfers.
> >
> > We can see the following
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Thursday, July 25, 2013 8:07 PM
>
> On Thursday, July 25, 2013 03:09:35 AM Zheng, Lv wrote:
> > -stable according to the previous conversation.
> >
> > > From: Rafael J. Wysocki [mailto:r...@sisk.pl]
>
> From: Corey Minyard [mailto:tcminy...@gmail.com]
> Sent: Friday, July 26, 2013 2:13 AM
>
> On 07/25/2013 07:06 AM, Rafael J. Wysocki wrote:
> > On Thursday, July 25, 2013 03:09:35 AM Zheng, Lv wrote:
> >> -stable according to the previous conversation.
> &g
> > On Thursday, July 25, 2013 03:09:35 AM Zheng, Lv wrote:
> > >> -stable according to the previous conversation.
> > >>
> > >>> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> > >>> Sent: Thursday, July 25, 2013 7:38 AM
> > >>
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Friday, July 26, 2013 4:27 AM
>
> On Tuesday, July 23, 2013 04:09:43 PM Lv Zheng wrote:
> > This patch adds reference couting for ACPI operation region handlers
> > to fix races caused by the ACPICA address space callback invocations.
> >
>
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Friday, July 26, 2013 5:59 AM
>
> On Tuesday, July 23, 2013 04:09:26 PM Lv Zheng wrote:
> > This patch uses reference counting to fix the race caused by the
> > unprotected ACPI IPMI user.
> >
> > As the acpi_ipmi_device->user_interface check
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Friday, July 26, 2013 6:23 AM
>
> On Tuesday, July 23, 2013 04:09:54 PM Lv Zheng wrote:
> > This patch adds reference counting for ACPI IPMI transfers to tune the
> > locking
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Friday, July 26, 2013 6:26 AM
>
> On Tuesday, July 23, 2013 04:10:06 PM Lv Zheng wrote:
> > This is a trivial patch:
> > 1. Deletes a member of the acpi_ipmi_device - smi_data which is not
> >actually used.
> > 2. Updates a member of the
> From: Corey Minyard [mailto:tcminy...@gmail.com]
> Sent: Friday, July 26, 2013 8:48 AM
>
> On 07/25/2013 07:16 PM, Zheng, Lv wrote:
> >>
> >> If I understand this correctly, the problem would be if:
> >>
> >> rem_time =
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Friday, July 26, 2013 5:29 AM
>
> On Tuesday, July 23, 2013 04:09:43 PM Lv Zheng wrote:
> > This patch adds reference couting for ACPI operation region handlers to fix
> > races caused by the ACPICA address space callback invocations.
> >
> >
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Thursday, July 25, 2013 8:04 PM
>
> CC-ing some of the tboot maintainers.
> > As what I've said, it's up to the others to determine if the patch is OK.
> > I just need to make my concerns visible in the community. :-)
>
> If I
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng, Lv
> Sent: Friday, July 26, 2013 8:48 AM
>
>
>
> > From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> > Sent: Friday, July 26, 2013 4:27 AM
> >
> >
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng, Lv
> Sent: Friday, July 26, 2013 9:54 AM
> To: Rafael J. Wysocki
> Cc: Wysocki, Rafael J; Brown, Len; linux-kernel@vger.kernel.org;
> linux-a...@vger.kernel.org
> Subj
> > Kconfig symbol ACPI_DEBUG_FUNC_TRACE was only used (through its
> > corresponding macro) in drivers/acpi/acpica/acmacros.h. That macro was
> > removed from that header in v3.8, with commit
> > 86ff0e508f88eda6e479a897476026055831d2d8 ("ACPICA: Fix unmerged
> > acmacros.h divergences."). That co
> > > Kconfig symbol ACPI_DEBUG_FUNC_TRACE was only used (through its
> > > corresponding macro) in drivers/acpi/acpica/acmacros.h. That macro
> > > was removed from that header in v3.8, with commit
> > > 86ff0e508f88eda6e479a897476026055831d2d8 ("ACPICA: Fix unmerged
> > > acmacros.h divergences."
> > > > Kconfig symbol ACPI_DEBUG_FUNC_TRACE was only used (through its
> > > > corresponding macro) in drivers/acpi/acpica/acmacros.h. That macro
> > > > was removed from that header in v3.8, with commit
> > > > 86ff0e508f88eda6e479a897476026055831d2d8 ("ACPICA: Fix unmerged
> > > > acmacros.h div
/generate/linux
Thanks
-Lv
> -Original Message-
> From: Tang Chen [mailto:tangc...@cn.fujitsu.com]
> Sent: Thursday, March 07, 2013 6:38 PM
> To: l...@kernel.org; r...@sisk.pl; Moore, Robert; Zheng, Lv;
> ming.m@intel.com; m...@selenic.com; herb...@gondor.apana.org.au;
> r..
> > > https://github.com/acpica/acpica/tree/master/generate/linux
> > Hi Lv,
> >
> > Thanks for telling me this. :)
> >
> > One more thing, if I want to fix something in acpica, such as this
> > patch set, who and which mail list should I send patches to ?
>
> Please post them to linux-a...@vger.k
> Hi Len,
>
> On Mon, 11 Feb 2013 18:34:06 -0500 Len Brown wrote:
> >
> > BTW. Rafael's "pm" tree now carries the ACPI patch stream, so it is
> > probably a mis-representation to call my tree the "acpi" tree.
> > My tree is primarily focused on the "idle" part of pm these days.
>
> OK, I have re
Forgot to Cc x86 maintainers, will send again. Sorry for the noise.
> -Original Message-
> From: Zheng, Lv
> Sent: Friday, September 28, 2012 10:40 AM
> To: Brown, Len
> Cc: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; Zheng, Lv
> Subject: [PATCH v4 0/2] ACP
Hi, Dmitry
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
>
> On Mon, Jul 11, 2016 at 01:34:08PM +0200, Benjamin Tissoires wrote:
> > On Fri, Jul 8, 2016 at 7:51 PM, Dmitry Toro
Hi, Dmitry
Thanks for the review.
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI control
> method lid device restrictions
>
> On Tue, Jul 19, 2016 at 04:11:21PM +0800, Lv Zheng wrote:
> > This patch adds documentatio
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH] tools/power/acpi/tools/acpidbg: Add multi-
> commands support in batch mode
>
> On Wednesday, July 20, 2016 04:12:08 PM Lv Zheng wrote:
> > This patch adds multi-commands support for the batch mode. The same
>
Hi,
> 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] ACPI / debugger: Add kernel flushing support
>
> On Tuesday, July 19, 2016 06:00:39 PM Lv Zheng wrote:
> > This patch adds debugger log flushing s
Hi, Dmitry
Thanks for the review.
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI control
> method lid device restrictions
>
> Hi Lv,
>
> On Fri, Jul 22, 2016 at 12:24:50AM +, Zheng, Lv
; On Fri, Jul 22, 2016 at 12:24:50AM +, Zheng, Lv wrote:
> >> Hi, Dmitry
> >>
> >>
> >> Thanks for the review.
> >>
> >> > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> >> > Subject: Re: [PATCH v4 2/2] ACPI / button:
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI control
> method lid device restrictions
>
> On Fri, Jul 22, 2016 at 10:47 AM, Zheng, Lv wrote:
> > Hi,
> >
&g
space tunes its behavior.
With PATCH 01, 2nd close can arrive to userspace, so that can be tuned to:
1. User space stops asking kernel to send open notification.
2. And only acts against "close" notification.
Thanks and best regards
-Lv
> From: Zheng, Lv
> Subject: [PATCH v5 1/
Hi, Dmitry
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Dmitry Torokhov
> Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI control
> method lid device restrictions
>
> On Fri, Jul 22, 2016 at 08:37:50AM +000
AM +0200, Benjamin Tissoires wrote:
> > On Fri, Jul 22, 2016 at 6:37 AM, Dmitry Torokhov
> > wrote:
> > > Hi Lv,
> > >
> > > On Fri, Jul 22, 2016 at 12:24:50AM +, Zheng, Lv wrote:
> > >> Hi, Dmitry
> > >>
> > >>
> >
Hi, Mika
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Subject: Re: [PATCH v3 1/5] ACPICA: Namespace: Fix a regression that MLC
> support triggers dead lock in dynamic table loading
>
> On Mon, Jun 20, 2016 at 05:07:22PM +0800, Lv Zheng wrote:
> > The new MLC approach invokes
Hi, Mika
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Subject: Re: [PATCH v4 1/5] ACPICA: Namespace: Fix a regression that MLC
> support triggers dead lock in dynamic table loading
>
> On Tue, Jun 21, 2016 at 12:34:15PM +0800, Lv Zheng wrote:
> > The new MLC approach invokes
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH v5 0/5] ACPI 2.0: Stop defer-executing module level code
>
> On Friday, September 23, 2016 11:26:26 AM Lv Zheng wrote:
> > After fixing ACPICA internal locking issues, we can enable the correct
> > grammar supp
Hi, Benjamin
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Benjamin Tissoires
> Subject: [PATCH] ACPI / button: remove pointer to old lid_sysfs on unbind
>
> When we removed the procfs dir on error or if the driver is
> unbound, the two variabl
Hi, Vegard
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Vegard Nossum
> Subject: [PATCH] ACPICA: cleanup method properly on error
>
> If the call to acpi_ds_init_aml_walk() fails, then we have to undo the
> walk state push done by acpi_ds_crea
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: [PATCH v2] ACPI / button: remove pointer to old lid_sysfs on
> unbind
>
> When we removed the procfs dir on error or if the driver is
> unbound, the two variables acpi_lid_dir and acpi_button_dir
> were not
Hi,
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: [PATCH 1/2] ACPICA: adapt buffer length for Field Attrib Raw
> Process in Ops Region
>
> Detected on the Surface 3:
> The MSHW0011 driver uses Field Attrib Raw Process to return information
> for the ACPI Battery. Th
The newline is intentional for acpiexec.
So you should fix this issue in acpiexec, aka, in ACPICA upstream.
Thanks
Lv
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Borislav
> Petkov
> Subject: [PATCH] ACPICA / Interpreter: Remove redundant newl
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Moore,
> Robert
> David E
> Subject: RE: [PATCH] ACPICA / Interpreter: Remove redundant newline
>
> Well, I never thought I would write a couple lines of code like this, but
> here is a soluti
Hi,
> From: Joe Perches [mailto:j...@perches.com]
> Subject: Re: [PATCH] ACPICA / Interpreter: Remove redundant newline
>
> On Fri, 2016-09-09 at 20:40 +0200, Borislav Petkov wrote:
> > On Fri, Sep 09, 2016 at 06:26:17PM +, Moore, Robert wrote:
> > > Is this a big deal?
> > > We do this on pu
Hi, Andrey
> From: Andrey Skvortsov [mailto:andrej.skvort...@gmail.com]
> Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
>
> On 24 Jun, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Andrey Skvortsov [mailto:andrej.skvort...@gmail.com]
> > > Subject:
> From: Alexander Kuleshov [mailto:kuleshovm...@gmail.com]
> Subject: [PATCH] ACPICA: Remove unnecessary '\n' in the end of
> ACPI_INFO output
>
> as the ACPI_INFO already prints `\n` in the end itself.
[Lv Zheng]
Looks good.
Acked-by: Lv Zheng
However this patch should go through ACPICA upstrea
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, 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: 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,
> 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, 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: 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,
> 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
; So, I'm 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;
>
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
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,
rnel.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 d
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,
> 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, 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, 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, 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: 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,
> 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
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
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
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 ||
d to be wrapped by such 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]
> Sen
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 acpi_unload_table_
]
> Sent: 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
> > >
> &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 0
is 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
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 ob
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 r
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: 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,
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
> r
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(&am
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:
> > acp
1 - 100 of 459 matches
Mail list logo
