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 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <1AE640813FDE7649BE1B193DEA596E8802643E0D@SHSMSX101.ccr.corp.intel.com> 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