lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 22 Jul 2014 01:25:00 +0000
From:	"Zheng, Lv" <lv.zheng@...el.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
CC:	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"Brown, Len" <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"Moore, Robert" <robert.moore@...el.com>
Subject: RE: [RFC PATCH v3 00/14] ACPI/EC: Add event storm prevention and
 cleanup command storm prevention.

Hi, Rafael

> From: Rafael J. Wysocki [mailto:rjw@...ysocki.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 merged from
> > ACPICA upstream.
> 
> Do I remember correctly that this is the plan?
> 
> So I'm expecting to receive the Linux versions of the relevant ACPICA changes
> from you and then I'll apply this material on top of them.
> 
> We don't need to wait for the next ACPICA release with this I think, but
> I'd like the GPE changes to be applied to upstream ACPICA at least before
> I get them.

Yes, I'm trying.
I'll re-send this series after an ACPICA release cycle that contains the dependent GPE series.

Let me highlight the real value of this EC series:
This is a good IO driver material to demonstrate:
1. runtime idle: this is not implemented yet because of ACPICA issues that are not root caused, let me show this possibility this below.
2. storming safe: can also deal with all kinds of silicon without worrying about IRQ storming.

On top of this, after
1. making sure that acpi_evaluate_object(_Qxx) won't be a blocking point, and extending the referenced period to the end of the evaluation,
2. adding 1 more patch to the ACPICA series, using a flag to bypass the automatic GPE disabling/enabling,
3. adding 1 more patch to make EC event poller  to disable GPE when sleeping,
Linux EC driver can run without GPE enabled when idle.
Which means GPE is enabled only when:
1. there is an EC command issued from the EC space handler or
2. the event poller thread is timed out or woken up by the EVT_SCI.

So I hope this IO driver enhancement can be a good material to show such possibility.

Thanks and best regards
-Lv

> 
> Rafael

Powered by blists - more mailing lists