ACPI: EC: do transaction from interrupt context

It is easier and faster to do transaction directly from interrupt context rather than waking control thread.
Also, cleaner GPE storm avoidance is implemented.
References: http://bugzilla.kernel.org/show_bug.cgi?id=9998

		http://bugzilla.kernel.org/show_bug.cgi?id=10724
		http://bugzilla.kernel.org/show_bug.cgi?id=10919
		http://bugzilla.kernel.org/show_bug.cgi?id=11309
		http://bugzilla.kernel.org/show_bug.cgi?id=11549

Signed-off-by Alexey Starikovskiy <[email protected]>

---

Quoted 3 lines · Alexey Starikovskiy

It is easier and faster to do transaction directly from interrupt context rather than waking control thread.
Also, cleaner GPE storm avoidance is implemented.

References: http://bugzilla.kernel.org/show_bug.cgi?id=9998

Quoted 6 lines

		http://bugzilla.kernel.org/show_bug.cgi?id=10724
		http://bugzilla.kernel.org/show_bug.cgi?id=10919
		http://bugzilla.kernel.org/show_bug.cgi?id=11309
		http://bugzilla.kernel.org/show_bug.cgi?id=11549

Signed-off-by Alexey Starikovskiy <[email protected]>

---

This resolves the slow hotkeys (e.g. brightness keys) that I see on my EeePC 900.

Tested-by Sitsofe Wheeler <[email protected]>

I think that the problem on the asus-EEEPC can't be resolved really
by the Alexey's patch. IMO it is only lucky.

In fact the main problem on Asus-EEEPC is related with the broken EC.
Before an EC notification event is processed, another EC notification event arrives again.
If EC driver check whether the SCI_EVT bit is set after processing
one EC notification event, the problem will be resolved.
http://bugzilla.kernel.org/show_bug.cgi?id=11089
Alan Jenkins already sent a patch about how to fix the issue on the
Asus-EEEPC.

But if the above patch is merged , maybe it will break some laptops.

Quoted 2 lines · Zhao Yakui

I think that the problem on the asus-EEEPC can't be resolved really
by the Alexey's patch. IMO it is only lucky.

How lucky? It really does go from excruciatingly slow to quite fast on that laptop. What will happen should my luck fail? What are the odds of my luck failing?

Quoted 8 lines

In fact the main problem on Asus-EEEPC is related with the broken EC.
Before an EC notification event is processed, another EC notification event arrives again.
If EC driver check whether the SCI_EVT bit is set after processing
one EC notification event, the problem will be resolved.
http://bugzilla.kernel.org/show_bug.cgi?id=11089
Alan Jenkins already sent a patch about how to fix the issue on the
Asus-EEEPC.

I'll cc Alan and see what he makes of this patch.

Quoted 1 line

But if the above patch is merged , maybe it will break some laptops.

Fair enough but can those people with such laptops test the patch too and report back? Can you say in what form the breakages will take? From what you are saying it sounds like this patch shouldn't have had any affect for me but it does. What happens when they try it? What happens when you try it?

Quoted 2 lines · Zhao Yakui

I think that the problem on the asus-EEEPC can't be resolved really
by the Alexey's patch. IMO it is only lucky.

How lucky? It really does go from excruciatingly slow to quite fast on that laptop. What will happen should my luck fail? What are the odds of my luck failing?

Quoted 7 lines

In fact the main problem on Asus-EEEPC is related with the broken EC.
Before an EC notification event is processed, another EC notification event arrives again.
If EC driver check whether the SCI_EVT bit is set after processing
one EC notification event, the problem will be resolved. http://bugzilla.kernel.org/show_bug.cgi?id=11089
Alan Jenkins already sent a patch about how to fix the issue on the
Asus-EEEPC.

I'll cc Alan and see what he makes of this patch.

Quoted 1 line

But if the above patch is merged , maybe it will break some laptops.

Fair enough but can those people with such laptops test the patch too and report back? Can you say in what form the breakages will take? From what you are saying it sounds like this patch shouldn't have had any affect for me but it does. What happens when they try it? What happens when you try it?

Quoted 8 lines · Sitsofe Wheeler

Quoted 2 lines · Zhao Yakui

I think that the problem on the asus-EEEPC can't be resolved really
by the Alexey's patch. IMO it is only lucky.

How lucky? It really does go from excruciatingly slow to quite fast on that laptop. What will happen should my luck fail? What are the odds of my luck failing?

Quoted 9 lines

Quoted 9 lines

In fact the main problem on Asus-EEEPC is related with the broken
EC.
Before an EC notification event is processed, another EC notification event arrives again.
If EC driver check whether the SCI_EVT bit is set after processing
one EC notification event, the problem will be resolved.
http://bugzilla.kernel.org/show_bug.cgi?id=11089
Alan Jenkins already sent a patch about how to fix the issue on the
Asus-EEEPC.

Quoted 2 lines

I'll cc Alan and see what he makes of this patch.

Alan already tested my patch and it works for him.

Quoted 8 lines

Quoted 1 line

But if the above patch is merged , maybe it will break some laptops.

Fair enough but can those people with such laptops test the patch too and report back? Can you say in what form the breakages will take? From what you are saying it sounds like this patch shouldn't have had any affect for me but it does. What happens when they try it? What happens when you try it?

Quoted 8 lines · Alexey Starikovskiy

Quoted 7 lines · Sitsofe Wheeler

Quoted 2 lines · Zhao Yakui

I think that the problem on the asus-EEEPC can't be resolved really
by the Alexey's patch. IMO it is only lucky.

How lucky? It really does go from excruciatingly slow to quite fast on that laptop. What will happen should my luck fail? What are the odds of my luck failing?

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

In fact the main problem on Asus-EEEPC is related with the broken
EC.
Before an EC notification event is processed, another EC notification event arrives again.
If EC driver check whether the SCI_EVT bit is set after processing
one EC notification event, the problem will be resolved. http://bugzilla.kernel.org/show_bug.cgi?id=11089
Alan Jenkins already sent a patch about how to fix the issue on the
Asus-EEEPC.

I submitted alternative patches in the past, but they were not up to scratch. The first patch stopped the EeePC dropping events, but left them arriving in bursts every 0.5 seconds - which is still a UI regression; it looks even more weird when you hold down a brightness key. My other patches fixed the EeePC, but caused severe regressions on other hardware.

So I have stopped pushing any patches of my own. In the interest of removing this regression as soon as reasonably possible, I will not object to changes that actually work.

Quoted 4 lines

Quoted 2 lines

I'll cc Alan and see what he makes of this patch.

Alan already tested my patch and it works for him.

Yup. I agree with Zhao, in that it is not crystal clear why this new patch helps.

The new patch includes a fallback which requires polling-driven transactions. That's a different type of polling fallback to the previous one. However, from the experience of testing a range of patches, I believe the new polling fallback would also drop events. At face value, the trigger for the polling fallback is the same - 20 "false" (surplus to requirements) interrupts, so it shouldn't work :-).

I can think of two possibilities

1. Doing more in the interrupt handler leaves the interrupt disabled for longer, hiding some of the false interrupts (which arrive in bursts).

2. Maybe when the device is serviced (e.g. a data byte is read), it stops the current burst of false interrupts.

Quoted 7 lines

Quoted 7 lines

Quoted 1 line

But if the above patch is merged , maybe it will break some laptops.

Fair enough but can those people with such laptops test the patch too and report back? Can you say in what form the breakages will take? From what you are saying it sounds like this patch shouldn't have had any affect for me but it does. What happens when they try it? What happens when you try it?

Alan

Alan,

Could you please uncomment DEBUG and send dmesg after application of the patch.
I put the "storm detected" message under debug, so it is not visible in normal situation.
I think, that interrupt storm is still detected on your machine, and workaround works.

Regards,
Alex.

Quoted 4 lines · Sitsofe Wheeler

Quoted 3 lines · Alexey Starikovskiy

It is easier and faster to do transaction directly from interrupt context rather than waking control thread.
Also, cleaner GPE storm avoidance is implemented.

Hi, Sitsofe
I think that the problem on the asus-EEEPC can't be resolved really
by the Alexey's patch. IMO it is only lucky.
In fact the main problem on Asus-EEEPC is related with the broken EC.
Before an EC notification event is processed, another EC notification event arrives again.
If EC driver check whether the SCI_EVT bit is set after processing
one EC notification event, the problem will be resolved.
http://bugzilla.kernel.org/show_bug.cgi?id=11089
Alan Jenkins already sent a patch about how to fix the issue on the
Asus-EEEPC.

But if the above patch is merged , maybe it will break some laptops.
On my laptop when issuing the query command, a non-zero query event is returned but it can't be processed.(There is no corresponding ACPI _Qxx object). At the same time the SCI_EVT bit won't be cleared. In such case OS can't exit the function of acpi_ec_query_handler, which causes that the acpid kernel thread can't work well.

Quoted 4 lines · Sitsofe Wheeler

Quoted 3 lines · Alexey Starikovskiy

It is easier and faster to do transaction directly from interrupt context rather than waking control thread.
Also, cleaner GPE storm avoidance is implemented.

Hi, Sitsofe
I think that the problem on the asus-EEEPC can't be resolved really
by the Alexey's patch. IMO it is only lucky.
In fact the main problem on Asus-EEEPC is related with the broken EC.
Before an EC notification event is processed, another EC notification event arrives again.
If EC driver check whether the SCI_EVT bit is set after processing
one EC notification event, the problem will be resolved.
http://bugzilla.kernel.org/show_bug.cgi?id=11089
Alan Jenkins already sent a patch about how to fix the issue on the
Asus-EEEPC.

But if the above patch is merged , maybe it will break some laptops.
On my laptop when issuing the query command, a non-zero query event is returned but it can't be processed.(There is no corresponding ACPI _Qxx object). At the same time the SCI_EVT bit won't be cleared. In such case OS can't exit the function of acpi_ec_query_handler, which causes that the acpid kernel thread can't work well.

Alan gives a suggestion that after processing the EC notification event, EC driver should continue to issue the query command and process the EC notification event until the query command returns zero.
But this suggestion will break my laptop. On my laptop when issuing the query command, a non-zero query event is returned but it can't be processed.(There is no corresponding ACPI _Qxx object). At the same time the SCI_EVT bit won't be cleared. In such case OS can't exit the function of acpi_ec_query_handler, which causes that the acpid kernel thread can't work well.

In fact according to my analysis IMO Alexey's patch will break my laptop.

But now the laptop is not in my hand and I can't do the test. After I own the laptop again, I will do the test and attach the corresponding info.

At the same time there are two generic issues in this patch:
a. spin_lock is overkill. When 2000 EC I/O read/write are executed, the CPU interrupt will be disabled for about 1.5ms. This will affect the normal laptops.

b. the local variable that resides in process stack space is used in interrupt-context.

Quoted 8 lines · Yakui

Alan gives a suggestion that after processing the EC notification event, EC driver
should continue to issue the query command and process the EC notification
event until the query command returns zero. But this suggestion will break my laptop. On my laptop when issuing the query command, a non-zero query event is returned but it can't be processed.(There
is no corresponding ACPI _Qxx object). At the same time the SCI_EVT bit won't
be cleared. In such case OS can't exit the function of acpi_ec_query_handler,
which causes that the acpid kernel thread can't work well.

Well, perhaps we should exit acpi_ec_query_handler() if SCI_EVT is clear _or_ the processing of an event fails due to the lack of a _Qxx object? Alex?

Quoted 2 lines

In fact according to my analysis IMO Alexey's patch will break my laptop.

That obviously would be a regression.

Quoted 4 lines

But now the laptop is not in my hand and I can't do the test. After I own the laptop again, I will do the test and attach the corresponding info.

OK, how much time is it going to take, approximately?

Quoted 5 lines

At the same time there are two generic issues in this patch:
a. spin_lock is overkill. When 2000 EC I/O read/write are executed, the CPU interrupt will be disabled for about 1.5ms. This will affect the normal laptops.

OTOH, I think we need _some_ locking in there in order to prevent races from happening.

Quoted 3 lines

b. the local variable that resides in process stack space is used in interrupt-context.

Which one?

Quoted 12 lines · Rafael J. Wysocki

Quoted 9 lines · Yakui

Alan gives a suggestion that after processing the EC notification event, EC driver should continue to issue the query command and process the EC notification event until the query command returns zero.
But this suggestion will break my laptop. On my laptop when issuing the query command, a non-zero query event is returned but it can't be processed.(There is no corresponding ACPI _Qxx object). At the same time the SCI_EVT bit won't be cleared. In such case OS can't exit the function of acpi_ec_query_handler, which causes that the acpid kernel thread can't work well.

Quoted 4 lines

Well, perhaps we should exit acpi_ec_query_handler() if SCI_EVT is clear _or_ the processing of an event fails due to the lack of a _Qxx object? Alex?

1. There is no such function acpi_ec_query_handler().
2. acpi_ec_gpe_query() does two things:
a) checks if EC returns non-zero query index. If EC has nothing to query -- it return 0 and we stop.
b) we check index with stored available handlers, and if there is such handler, we execute it.
This function is scheduled to run in response to raised SCI_EVT, and as I know no EC which would clear SCI_EVT by itself (and it's against spec),
there is no reason to check if it's raised inside the function. SCI_EVT is cleared by EC in response to QUERY command issued by driver, and this is always done in acpi_ec_gpe_query().

We (Alan and me) already found that machines in 9998 would break if you try to do several QUERY commands for single raise of SCI_EVT in a hope to "clean the EC query buffer" -- EC would just return _same_ event over and over, thus
driver does not try to do this. Please not mix patch from Alan (with above query loop)
with my patch(it never had above query loop).

Quoted 5 lines

Quoted 2 lines

In fact according to my analysis IMO Alexey's patch will break my laptop.

That obviously would be a regression.

I highly suspect quality of such "analysis" based on 2 weeks of conversation with
Yakui. Feel free to make your own judgment though...

Quoted 7 lines

Quoted 3 lines

But now the laptop is not in my hand and I can't do the test. After I own the laptop again, I will do the test and attach the corresponding info.

OK, how much time is it going to take, approximately?

Quoted 10 lines

Quoted 5 lines

At the same time there are two generic issues in this patch:
a. spin_lock is overkill. When 2000 EC I/O read/write are executed, the CPU interrupt will be disabled for about 1.5ms. This will affect the normal laptops.

OTOH, I think we need _some_ locking in there in order to prevent races from happening.

He used 1000 EC I/O per second before, and now it's raised to 2000 just to make a good number. One full read of battery with SBS (most irq-intensive)
is in order of 100 GPEs. You need to update your battery state 20 times per second
to get this number.
I will not try to doubt 0.7usec of inb/outb operation to EC, but my understanding
is that you don't wait while LPC transaction is over, so it is inb/outb to south bridge
which needs to be counted.
Irq handler itself will disable interrupts as well, it will read several ACPI GPE registers
in order to find GPE bit, which caused interrupt (first delay). second, even the most dumb GPE EC handler needs to read status register of EC
(second delay).
Now, my patch adds either read or write of EC data register to this (third delay).

So, in the very worst case of 0.7usec access to EC register (and free GPE register access),
we will disable interrupt for 1.5usec instead of 0.7usec.
Notice, we enable interrupt between each of these 1.5usec intervals. Notice also, spinlock does not add anything to these timings.

Quoted 7 lines

Quoted 3 lines

b. the local variable that resides in process stack space is used in interrupt-context.

Which one?

He refers to the ec->curr (former ec->t).

Quoted 1 line

He refers to the ec->curr (former ec->t).

Hm, I'm not sure what the failing scenario in this case would be.

Quoted 3 lines · Rafael J. Wysocki

Quoted 1 line

He refers to the ec->curr (former ec->t).

Hm, I'm not sure what the failing scenario in this case would be.

Last one was the thread of the stack is killed during transaction, thus stack vanishes and interrupt goes over freed memory.

Quoted 4 lines · Alexey Starikovskiy

Quoted 2 lines · Rafael J. Wysocki

Quoted 2 lines

He refers to the ec->curr (former ec->t).

Quoted 5 lines

Quoted 2 lines

Hm, I'm not sure what the failing scenario in this case would be.

Last one was the thread of the stack is killed during transaction, thus stack vanishes and interrupt goes over freed memory.

This isn't possible IMO. The thread is uninterruptible while waiting for the transaction to finish (if I'm not mistaken).

That said, we can still embed 'curr' in 'struct acpi_ec' and do 'ec.curr = t' instead of 'ec->curr = &t' in acpi_ec_transaction_unlocked(). Now, if 'command' is embedded in 'curr', it will be sufficient to do 'if (curr.command)' instead of doing 'if (ec->curr)', wherever applicable.

Quoted 6 lines · Rafael J. Wysocki

Quoted 4 lines · Alexey Starikovskiy

Quoted 2 lines · Rafael J. Wysocki

Quoted 2 lines

He refers to the ec->curr (former ec->t).

Quoted 9 lines

Quoted 5 lines

Quoted 2 lines

Hm, I'm not sure what the failing scenario in this case would be.

Last one was the thread of the stack is killed during transaction, thus stack vanishes and interrupt goes over freed memory.

This isn't possible IMO. The thread is uninterruptible while waiting for the transaction to finish (if I'm not mistaken).

Right, I already explained it to Yakui, this is why he only claims "ugly" now.

Quoted 5 lines

That said, we can still embed 'curr' in 'struct acpi_ec' and do 'ec.curr = t' instead of 'ec->curr = &t' in acpi_ec_transaction_unlocked(). Now, if 'command' is embedded in 'curr', it will be sufficient to do 'if (curr.command)' instead of doing 'if (ec->curr)', wherever applicable.

No, I like current way more. Now it is not possible to use transaction data if
acpi_ec_transaction is not on the stack.

Quoted 8 lines · Yakui

Alan gives a suggestion that after processing the EC notification event, EC driver should continue to issue the query command and process the EC notification event until the query command returns zero.
But this suggestion will break my laptop. On my laptop when issuing the query command, a non-zero query event is returned but it can't be processed.(There is no corresponding ACPI _Qxx object). At the same time the SCI_EVT bit won't be cleared. In such case OS can't exit the function of acpi_ec_query_handler, which causes that the acpid kernel thread can't work well.

Well, perhaps we should exit acpi_ec_query_handler() if SCI_EVT is clear _or_ the processing of an event fails due to the lack of a _Qxx object? Alex?

Quoted 1 line

In fact according to my analysis IMO Alexey's patch will break my laptop.

That obviously would be a regression.

Quoted 2 lines

But now the laptop is not in my hand and I can't do the test. After I own the laptop again, I will do the test and attach the corresponding info.

OK, how much time is it going to take, approximately?

Quoted 5 lines

At the same time there are two generic issues in this patch:
a. spin_lock is overkill. When 2000 EC I/O read/write are executed, the CPU interrupt will be disabled for about 1.5ms. This will affect the normal laptops.

OTOH, I think we need _some_ locking in there in order to prevent races from happening.

Quoted 2 lines

b. the local variable that resides in process stack space is used in interrupt-context.

Which one?

Rafael

Quoted 13 lines · Rafael J. Wysocki

Quoted 8 lines · Yakui

Alan gives a suggestion that after processing the EC notification event, EC driver should continue to issue the query command and process the EC notification event until the query command returns zero.
But this suggestion will break my laptop. On my laptop when issuing the query command, a non-zero query event is returned but it can't be processed.(There is no corresponding ACPI _Qxx object). At the same time the SCI_EVT bit won't be cleared. In such case OS can't exit the function of acpi_ec_query_handler, which causes that the acpid kernel thread can't work well.

Well, perhaps we should exit acpi_ec_query_handler() if SCI_EVT is clear _or_ the processing of an event fails due to the lack of a _Qxx object? Alex?

Quoted 8 lines

Quoted 1 line

In fact according to my analysis IMO Alexey's patch will break my laptop.

That obviously would be a regression.

Quoted 2 lines

But now the laptop is not in my hand and I can't do the test. After I own the laptop again, I will do the test and attach the corresponding info.

OK, how much time is it going to take, approximately?

Maybe I can own the laptop again after two days. And I will try to do the test as early as possible and attach the test result.

Quoted 6 lines

Quoted 5 lines

At the same time there are two generic issues in this patch:
a. spin_lock is overkill. When 2000 EC I/O read/write are executed, the CPU interrupt will be disabled for about 1.5ms. This will affect the normal laptops.

Quoted 2 lines

OTOH, I think we need _some_ locking in there in order to prevent races from happening.

Agree with what you said. The locking mechanism is needed to prevent the races from happening.
But in current source code the EC transaction is done in control thread. In such case there is no need to use the spin_lock.(Mutex lock is already used).

If we add the spin_lock for the broken BIOS/laptops , I agree with this method and regard it very reasonable. But if this mechanism also affects the normal laptops, IMO this is not unreasonable.

Quoted 2 lines

Quoted 2 lines

b. the local variable that resides in process stack space is used in interrupt-context.

The pointer of local variable in the function of
acpi_ec_transaction_unlocked is assigned to ec->t(this is regarded as the global variable). And ec->t is accessed in interrupt-context. Although it won't break anything, IMO this looks so ugly.

Quoted 3 lines

Quoted 1 line

OK, how much time is it going to take, approximately?

Maybe I can own the laptop again after two days. And I will try to do the test as early as possible and attach the test result.

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

At the same time there are two generic issues in this patch:
a. spin_lock is overkill. When 2000 EC I/O read/write are executed, the CPU interrupt will be disabled for about 1.5ms. This will affect the normal laptops.

OTOH, I think we need _some_ locking in there in order to prevent races from happening.

Quoted 5 lines

Agree with what you said. The locking mechanism is needed to prevent the races from happening.
But in current source code the EC transaction is done in control thread. In such case there is no need to use the spin_lock.(Mutex lock is already used).

IOW, it's done synchronously.

Quoted 3 lines

If we add the spin_lock for the broken BIOS/laptops , I agree with this method and regard it very reasonable. But if this mechanism also affects the normal laptops, IMO this is not unreasonable.

That really depends on how the "normal" laptops are affected and to what extent. Also, I'm not sure what the meaning of "normal" is in that case. Namely, if you define "normal" as "working with our current code well" and everything else as "broken", then the entire discussion doesn't make sense from that point on.

The question is whether there are machines that _should_ work correctly and they don't because _we_ try to handle them in a wrong way. If the answer is "yes", then our current code is inadequate and we have to change it, this way or another. I personally think that the Alex's patch goes in the right direction.

Quoted 6 lines

Quoted 2 lines

Quoted 2 lines

b. the local variable that resides in process stack space is used in interrupt-context.

The pointer of local variable in the function of
acpi_ec_transaction_unlocked is assigned to ec->t(this is regarded as the global variable). And ec->t is accessed in interrupt-context. Although it won't break anything, IMO this looks so ugly.

Well, I can agree with that. We can embed the 'struct transaction_data' (or whatever it's going to be called) in 'struct acpi_ec' and copy the values into it instead of using the pointer (ISTR, this is how it was done in the first iterations of the Alex's patch and the pointer was my idea).

Thanks,
Rafael

Of course such laptops can still work well except that CPU
interrupt will be disabled for some extra time after Alexey's patch is applied .(The some extra time depends on how many EC Inb/out operations are executed).

In my email the purpose that I point out 2000 EC I/O read/write operation doesn't indicate that 2000 EC I/O read/write will be executed per second. What I want to say is that EC I/O read/write is slow operation. If quite a lot of EC I/O read/write are accessed for some reasons in some time, the CPU interrupt will be disabled for a long time. In such case the normal laptop will be affected by this. (Of course maybe the affect will be very tiny).
In fact in kernel source code if the race can be resolved by other
synchronization protection mechanism, the spin_lock had better be avoided.

Quoted 6 lines · Zhao Yakui

Of course such laptops can still work well except that CPU
interrupt will be disabled for some extra time after Alexey's patch is applied .(The some extra time depends on how many EC Inb/out operations are executed).

spinlock is released after each I/O, so by your own calculation it is disabled for 1.5 usec.

You can then multiply this number by lifetime of the universe, it does not mean anything.

Regards,
Alex.

Quoted 11 lines

In my email the purpose that I point out 2000 EC I/O read/write operation doesn't indicate that 2000 EC I/O read/write will be executed per second. What I want to say is that EC I/O read/write is slow operation. If quite a lot of EC I/O read/write are accessed for some reasons in some time, the CPU interrupt will be disabled for a long time. In such case the normal laptop will be affected by this. (Of course maybe the affect will be very tiny).
In fact in kernel source code if the race can be resolved by other
synchronization protection mechanism, the spin_lock had better be avoided.

Please explain, I'd like to make poster of it :)

I agree with what you have done.

It is easier and faster to do transaction directly from interrupt context rather than waking control thread.
Also, cleaner GPE storm avoidance is implemented.
References: http://bugzilla.kernel.org/show_bug.cgi?id=9998

		http://bugzilla.kernel.org/show_bug.cgi?id=10724
		http://bugzilla.kernel.org/show_bug.cgi?id=10919
		http://bugzilla.kernel.org/show_bug.cgi?id=11309
		http://bugzilla.kernel.org/show_bug.cgi?id=11549

Signed-off-by Alexey Starikovskiy <[email protected]>

---

 drivers/acpi/ec.c |  309 ++++++++++++++++++++++++++---------------------------
 1 files changed, 149 insertions(+), 160 deletions(-)

drivers/acpi/ec.c +1 -1

index 13593f9..7f0d81c 100644
@@ -1,7 +1,7 @@
 /*
- *  ec.c - ACPI Embedded Controller Driver (v2.0)
+ *  ec.c - ACPI Embedded Controller Driver (v2.1)
  *