FAILED: patch "[PATCH] ACPI / EC: Fix a code coverity issue when QR_EC transactions" failed to apply to 4.1-stable tree

FAILED: patch "[PATCH] ACPI / EC: Fix a code coverity issue when QR_EC transactions" failed to apply to 4.1-stable tree

[gregkh]

The patch below does not apply to the 4.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

>From 66db383439b51b1aa920f3579da644fb5fdb2b7c Mon Sep 17 00:00:00 2001
From: Lv Zheng <lv.zheng@intel.com>
Date: Thu, 11 Jun 2015 13:21:51 +0800
Subject: [PATCH] ACPI / EC: Fix a code coverity issue when QR_EC transactions
 are failed.

When the QR_EC transaction fails, the EC_FLAGS_QUERY_PENDING flag prevents
the event handling work queue from being scheduled again.

Though there shouldn't be failed QR_EC transactions, and this gap was
efficiently used for catching and learning the SCI_EVT clearing timing
compliance issues, we need to fix this as we are not fully compatible
with all platforms/Windows to handle SCI_EVT clearing timing correctly.
Fixing this gives the EC driver the chances to recover from a state machine
failure.

So this patch fixes this issue. When nr_pending_queries drops to 0, it
clears EC_FLAGS_QUERY_PENDING at the proper position for different modes in
order to ensure that the SCI_EVT handling can proceed.

In order to be clearer for future ec_event_clearing modes, all checks in
this patch are written in the inclusive style, not the exclusive style.

Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 79817ce164c1..9d4761d2f6b7 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -512,7 +512,8 @@ static void advance_transaction(struct acpi_ec *ec)
 	 */
 	if (!t || !(t->flags & ACPI_EC_COMMAND_POLL)) {
 		if (ec_event_clearing == ACPI_EC_EVT_TIMING_EVENT &&
-		    test_bit(EC_FLAGS_QUERY_GUARDING, &ec->flags)) {
+		    (!ec->nr_pending_queries ||
+		     test_bit(EC_FLAGS_QUERY_GUARDING, &ec->flags))) {
 			clear_bit(EC_FLAGS_QUERY_GUARDING, &ec->flags);
 			acpi_ec_complete_query(ec);
 		}
@@ -1065,6 +1066,17 @@ static void acpi_ec_event_handler(struct work_struct *work)
 		(void)acpi_ec_query(ec, NULL);
 		spin_lock_irqsave(&ec->lock, flags);
 		ec->nr_pending_queries--;
+		/*
+		 * Before exit, make sure that this work item can be
+		 * scheduled again. There might be QR_EC failures, leaving
+		 * EC_FLAGS_QUERY_PENDING uncleared and preventing this work
+		 * item from being scheduled again.
+		 */
+		if (!ec->nr_pending_queries) {
+			if (ec_event_clearing == ACPI_EC_EVT_TIMING_STATUS ||
+			    ec_event_clearing == ACPI_EC_EVT_TIMING_QUERY)
+				acpi_ec_complete_query(ec);
+		}
 	}
 	spin_unlock_irqrestore(&ec->lock, flags);
 

RE: FAILED: patch "[PATCH] ACPI / EC: Fix a code coverity issue when QR_EC transactions" failed to apply to 4.1-stable tree

[Zheng, Lv]

Hi, Greg

I checked the EC bug-fixing commits on top of the linux-3.19.y stable branch.
It looks these 2 bug fixes now depend on the following commits.
And I tested a kernel by simply cherry picking the following commits on top of linux-3.19.y branch, it worked well.

1. 1st series, EC state machine fixes:
commit	0c78808f51d11564a29728091e87b80d6e54d499
ACPI / EC: Cleanup transaction wakeup code
commit	01305d4139cd345aa9f64cecfd7fc7b237e1444e
ACPI / EC: Add reference counting for query handlers
commit	c2cf5769fae1ce208ea00fa85298d1d19969300a
+ ACPI / EC: Fix returning values in acpi_ec_sync_query()
commit	f3e14329517ee190d34455d729430ef9d0473675
+ ACPI / EC: Fix a code path that global lock is not held
commit	74443bbed72ab22ee005ecb6ecdc657a8018e1db
+ ACPI / EC: Fix issues related to the SCI_EVT handling
commit	550b3aac5a72c4209f1ad3bc0ade663d5cb36f7f
ACPI / EC: Cleanup QR_EC related code

Though no direct user bugs are related to these fixes, this series makes the EC state machine handling synchronized (less racy).
And the later fixes are all based on the new less racy state machine implementation.
So IMO, it really need also be a stable material.

2. 2nd series, some tiny GPE cleanups:
commit	1c4c81a244a91a8ba37df3de33decca5d95cff0b
ACPICA: Events: Back port "ACPICA: Save current masks of enabled GPEs after enable register writes"
commit	833bb9316a3b4644b2671317ec4889e343ae5d42 (patch)
ACPICA: Events: Remove duplicated sanity check in acpi_ev_enable_gpe()
commit	b18da580343b88fa33bbba8a7f48392447bc6cbf
ACPICA: Events: Remove acpi_ev_valid_gpe_event() due to current restriction
commit	b7be6883c7b0414f72c785b498d133194151cd8b
ACPICA: Events: Fix uninitialized variable
commit	c539251e7c1537c8b3dcaa1c89f5393d04996013
ACPICA: Events: Cleanup of resetting the GPE handler to NULL before removing
commit	779ba5a39214f0e3112bd2b94c26df03dc518a29
ACPICA: Events: Cleanup to move acpi_gbl_global_event_handler invocation out of acpi_ev_gpe_dispatch()
commit	7c43312af8b363b679d1e7840858ff8d204a4d91
+ ACPICA: Events: Cleanup GPE dispatcher type obtaining code
commit	d6c02669b486a7742a27e9f3a7a66148a5a7c248
ACPICA: Hardware: Cast GPE enable_mask before storing

This may not be directly related to this fix, but the code here are all useful small fixes for the GPE implementation.

3. 3rd series, GPE raw handler mode and EC cleanup:
commit	0d0988af81ac809b30f818f0c0f065327ff6423b
ACPICA: Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix 2 issues for the current GPE APIs
commit	eb3d80f729e07394685239ddd137fbee5c13a2ea
ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergences
commit	2eedd3d8398b266ee8e846ded03218bb6a00e2c1
ACPICA: Events: Enable APIs to allow interrupt/polling adaptive request based GPE handling model
commit	ca37bfdfbc8d0a3ec73e4b97bb26dcfa51d515aa
* ACPI / EC: Fix several GPE handling issues by deploying ACPI_GPE_DISPATCH_RAW_HANDLER mode.
commit	9e295ac14d6a59180beed0735e6a504c2ee87761
ACPI / EC: Reduce ec_poll() by referencing the last register access timestamp.

The "*" marked fix is important.
Currently EC driver need to work during the suspend/resume noirq period.
So this driver is required to handle EC IRQs from both task context and the IRQ context.
And the fix along with the previous state machine synchronization fixes can help to avoid races between the 2 contexts.

4. 4th series, EC transaction flushing:
commit	ad479e7f47ca09c3f3190603ead4d01cf8fe6fa8
ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag
commit	9887d22add48f24ca3a7605c89b0a21ed337f185
ACPI / EC: Add command flushing support.
commit	e1d4d90fc0313d3d58cbd7912c90f8ef24df45ff
+ ACPI / EC: Refine command storm prevention support

This may not be directly related to this fix, but the code here are all useful small fixes.

5. 5th series, some EC debugging enhancement:
commit	92e4b1bcd6561ff702a57150a00254b8936ea835
ACPI / EC: Remove non-standard log emphasis
commit	3535a3c126651616a111491726c241e801fd9418
ACPI / EC: Cleanup logging/debugging splitter support.

The 2 patches are not necessarily be stable materials.
Without these 2 patches, some of the latter patches need to be modified to use old logging/debugging implementation.
It will be easier to just cherry pick these 2 fixes.

6. 6th series, some commits from EC polling cleanup:
commit	373783e6e9394b0dd5050eba152f436e08577d69
ACPI / EC: Remove irqs_disabled() check.
commit	d8d031a605bff183b76611e0d18e2ca7021fb99f
* ACPI / EC: Fix and clean up register access guarding logics.

The "*" marked fix is useful but may not be important as our default EC event clearing mode doesn't require this.
It reveals a hidden logic and one of the EC event clearing mode requires this hidden logic.
Without these 2 patches, some of the latter patches need to be modified to remove the non-default EC event clearing mode implementation.
It will be easier to just cherry pick these 2 fixes.

7. 7th series, EC event clearing timing:
commit	f8b8eb71533338654f39211a87efeca35055566b
ACPI / EC: Cleanup transaction state transition.
commit	9d8993be2d9149bc8b3132dad030ff5960f5abcc
ACPI / EC: Convert event handling work queue into loop style.
commit	1d68d2612c2e7309166fa43d8e27eb163435527f
ACPI / EC: Add event clearing variation support.
commit	3cb02aeb28dd3f1b8a132fa3ecf6db17afd518d6
* ACPI / EC: Fix EC_FLAGS_QUERY_HANDSHAKE platforms using new event clearing timing.
commit	66db383439b51b1aa920f3579da644fb5fdb2b7c
* ACPI / EC: Fix a code coverity issue when QR_EC transactions are failed.

This series fixes the user reported EC bugs.
It seems we do need the 2 "*" marked fixes as there will be more and more such platforms reported for the kernels that do not contain these 2 fixes.

The above commits contain some bug fixes that matters for a stable kernel (in additional to "*", marked by "+").
For linux-3.16.y tree, I'll check and report back later.

Thanks and best regards
-Lv

> From: gregkh@linuxfoundation.org [mailto:gregkh@linuxfoundation.org]
> Sent: Friday, July 17, 2015 6:08 AM
> 
> 
> The patch below does not apply to the 4.1-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> thanks,
> 
> greg k-h
> 
> ------------------ original commit in Linus's tree ------------------
> 
> From 66db383439b51b1aa920f3579da644fb5fdb2b7c Mon Sep 17 00:00:00 2001
> From: Lv Zheng <lv.zheng@intel.com>
> Date: Thu, 11 Jun 2015 13:21:51 +0800
> Subject: [PATCH] ACPI / EC: Fix a code coverity issue when QR_EC transactions
>  are failed.
> 
> When the QR_EC transaction fails, the EC_FLAGS_QUERY_PENDING flag prevents
> the event handling work queue from being scheduled again.
> 
> Though there shouldn't be failed QR_EC transactions, and this gap was
> efficiently used for catching and learning the SCI_EVT clearing timing
> compliance issues, we need to fix this as we are not fully compatible
> with all platforms/Windows to handle SCI_EVT clearing timing correctly.
> Fixing this gives the EC driver the chances to recover from a state machine
> failure.
> 
> So this patch fixes this issue. When nr_pending_queries drops to 0, it
> clears EC_FLAGS_QUERY_PENDING at the proper position for different modes in
> order to ensure that the SCI_EVT handling can proceed.
> 
> In order to be clearer for future ec_event_clearing modes, all checks in
> this patch are written in the inclusive style, not the exclusive style.
> 
> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index 79817ce164c1..9d4761d2f6b7 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -512,7 +512,8 @@ static void advance_transaction(struct acpi_ec *ec)
>  	 */
>  	if (!t || !(t->flags & ACPI_EC_COMMAND_POLL)) {
>  		if (ec_event_clearing == ACPI_EC_EVT_TIMING_EVENT &&
> -		    test_bit(EC_FLAGS_QUERY_GUARDING, &ec->flags)) {
> +		    (!ec->nr_pending_queries ||
> +		     test_bit(EC_FLAGS_QUERY_GUARDING, &ec->flags))) {
>  			clear_bit(EC_FLAGS_QUERY_GUARDING, &ec->flags);
>  			acpi_ec_complete_query(ec);
>  		}
> @@ -1065,6 +1066,17 @@ static void acpi_ec_event_handler(struct work_struct *work)
>  		(void)acpi_ec_query(ec, NULL);
>  		spin_lock_irqsave(&ec->lock, flags);
>  		ec->nr_pending_queries--;
> +		/*
> +		 * Before exit, make sure that this work item can be
> +		 * scheduled again. There might be QR_EC failures, leaving
> +		 * EC_FLAGS_QUERY_PENDING uncleared and preventing this work
> +		 * item from being scheduled again.
> +		 */
> +		if (!ec->nr_pending_queries) {
> +			if (ec_event_clearing == ACPI_EC_EVT_TIMING_STATUS ||
> +			    ec_event_clearing == ACPI_EC_EVT_TIMING_QUERY)
> +				acpi_ec_complete_query(ec);
> +		}
>  	}
>  	spin_unlock_irqrestore(&ec->lock, flags);
> 

Re: FAILED: patch "[PATCH] ACPI / EC: Fix a code coverity issue when QR_EC transactions" failed to apply to 4.1-stable tree

[gregkh]

On Fri, Jul 24, 2015 at 05:54:53AM +0000, Zheng, Lv wrote:
> Hi, Greg
> 
> I checked the EC bug-fixing commits on top of the linux-3.19.y stable branch.
> It looks these 2 bug fixes now depend on the following commits.
> And I tested a kernel by simply cherry picking the following commits on top of linux-3.19.y branch, it worked well.

Why are you asking me about 3.19.y stuff?  This is for 4.1, right?

I don't understand what you are wanting me to do with the 4.1-stable
kernel, please explain.

confused,

greg k-h

> 
> 1. 1st series, EC state machine fixes:
> commit	0c78808f51d11564a29728091e87b80d6e54d499
> ACPI / EC: Cleanup transaction wakeup code
> commit	01305d4139cd345aa9f64cecfd7fc7b237e1444e
> ACPI / EC: Add reference counting for query handlers
> commit	c2cf5769fae1ce208ea00fa85298d1d19969300a
> + ACPI / EC: Fix returning values in acpi_ec_sync_query()
> commit	f3e14329517ee190d34455d729430ef9d0473675
> + ACPI / EC: Fix a code path that global lock is not held
> commit	74443bbed72ab22ee005ecb6ecdc657a8018e1db
> + ACPI / EC: Fix issues related to the SCI_EVT handling
> commit	550b3aac5a72c4209f1ad3bc0ade663d5cb36f7f
> ACPI / EC: Cleanup QR_EC related code
> 
> Though no direct user bugs are related to these fixes, this series makes the EC state machine handling synchronized (less racy).
> And the later fixes are all based on the new less racy state machine implementation.
> So IMO, it really need also be a stable material.
> 
> 2. 2nd series, some tiny GPE cleanups:
> commit	1c4c81a244a91a8ba37df3de33decca5d95cff0b
> ACPICA: Events: Back port "ACPICA: Save current masks of enabled GPEs after enable register writes"
> commit	833bb9316a3b4644b2671317ec4889e343ae5d42 (patch)
> ACPICA: Events: Remove duplicated sanity check in acpi_ev_enable_gpe()
> commit	b18da580343b88fa33bbba8a7f48392447bc6cbf
> ACPICA: Events: Remove acpi_ev_valid_gpe_event() due to current restriction
> commit	b7be6883c7b0414f72c785b498d133194151cd8b
> ACPICA: Events: Fix uninitialized variable
> commit	c539251e7c1537c8b3dcaa1c89f5393d04996013
> ACPICA: Events: Cleanup of resetting the GPE handler to NULL before removing
> commit	779ba5a39214f0e3112bd2b94c26df03dc518a29
> ACPICA: Events: Cleanup to move acpi_gbl_global_event_handler invocation out of acpi_ev_gpe_dispatch()
> commit	7c43312af8b363b679d1e7840858ff8d204a4d91
> + ACPICA: Events: Cleanup GPE dispatcher type obtaining code
> commit	d6c02669b486a7742a27e9f3a7a66148a5a7c248
> ACPICA: Hardware: Cast GPE enable_mask before storing
> 
> This may not be directly related to this fix, but the code here are all useful small fixes for the GPE implementation.
> 
> 3. 3rd series, GPE raw handler mode and EC cleanup:
> commit	0d0988af81ac809b30f818f0c0f065327ff6423b
> ACPICA: Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix 2 issues for the current GPE APIs
> commit	eb3d80f729e07394685239ddd137fbee5c13a2ea
> ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergences
> commit	2eedd3d8398b266ee8e846ded03218bb6a00e2c1
> ACPICA: Events: Enable APIs to allow interrupt/polling adaptive request based GPE handling model
> commit	ca37bfdfbc8d0a3ec73e4b97bb26dcfa51d515aa
> * ACPI / EC: Fix several GPE handling issues by deploying ACPI_GPE_DISPATCH_RAW_HANDLER mode.
> commit	9e295ac14d6a59180beed0735e6a504c2ee87761
> ACPI / EC: Reduce ec_poll() by referencing the last register access timestamp.
> 
> The "*" marked fix is important.
> Currently EC driver need to work during the suspend/resume noirq period.
> So this driver is required to handle EC IRQs from both task context and the IRQ context.
> And the fix along with the previous state machine synchronization fixes can help to avoid races between the 2 contexts.
> 
> 4. 4th series, EC transaction flushing:
> commit	ad479e7f47ca09c3f3190603ead4d01cf8fe6fa8
> ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag
> commit	9887d22add48f24ca3a7605c89b0a21ed337f185
> ACPI / EC: Add command flushing support.
> commit	e1d4d90fc0313d3d58cbd7912c90f8ef24df45ff
> + ACPI / EC: Refine command storm prevention support
> 
> This may not be directly related to this fix, but the code here are all useful small fixes.
> 
> 5. 5th series, some EC debugging enhancement:
> commit	92e4b1bcd6561ff702a57150a00254b8936ea835
> ACPI / EC: Remove non-standard log emphasis
> commit	3535a3c126651616a111491726c241e801fd9418
> ACPI / EC: Cleanup logging/debugging splitter support.
> 
> The 2 patches are not necessarily be stable materials.
> Without these 2 patches, some of the latter patches need to be modified to use old logging/debugging implementation.
> It will be easier to just cherry pick these 2 fixes.
> 
> 6. 6th series, some commits from EC polling cleanup:
> commit	373783e6e9394b0dd5050eba152f436e08577d69
> ACPI / EC: Remove irqs_disabled() check.
> commit	d8d031a605bff183b76611e0d18e2ca7021fb99f
> * ACPI / EC: Fix and clean up register access guarding logics.
> 
> The "*" marked fix is useful but may not be important as our default EC event clearing mode doesn't require this.
> It reveals a hidden logic and one of the EC event clearing mode requires this hidden logic.
> Without these 2 patches, some of the latter patches need to be modified to remove the non-default EC event clearing mode implementation.
> It will be easier to just cherry pick these 2 fixes.
> 
> 7. 7th series, EC event clearing timing:
> commit	f8b8eb71533338654f39211a87efeca35055566b
> ACPI / EC: Cleanup transaction state transition.
> commit	9d8993be2d9149bc8b3132dad030ff5960f5abcc
> ACPI / EC: Convert event handling work queue into loop style.
> commit	1d68d2612c2e7309166fa43d8e27eb163435527f
> ACPI / EC: Add event clearing variation support.
> commit	3cb02aeb28dd3f1b8a132fa3ecf6db17afd518d6
> * ACPI / EC: Fix EC_FLAGS_QUERY_HANDSHAKE platforms using new event clearing timing.
> commit	66db383439b51b1aa920f3579da644fb5fdb2b7c
> * ACPI / EC: Fix a code coverity issue when QR_EC transactions are failed.
> 
> This series fixes the user reported EC bugs.
> It seems we do need the 2 "*" marked fixes as there will be more and more such platforms reported for the kernels that do not contain these 2 fixes.
> 
> The above commits contain some bug fixes that matters for a stable kernel (in additional to "*", marked by "+").
> For linux-3.16.y tree, I'll check and report back later.
> 
> Thanks and best regards
> -Lv
> 
> > From: gregkh@linuxfoundation.org [mailto:gregkh@linuxfoundation.org]
> > Sent: Friday, July 17, 2015 6:08 AM
> > 
> > 
> > The patch below does not apply to the 4.1-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > ------------------ original commit in Linus's tree ------------------
> > 
> > From 66db383439b51b1aa920f3579da644fb5fdb2b7c Mon Sep 17 00:00:00 2001
> > From: Lv Zheng <lv.zheng@intel.com>
> > Date: Thu, 11 Jun 2015 13:21:51 +0800
> > Subject: [PATCH] ACPI / EC: Fix a code coverity issue when QR_EC transactions
> >  are failed.
> > 
> > When the QR_EC transaction fails, the EC_FLAGS_QUERY_PENDING flag prevents
> > the event handling work queue from being scheduled again.
> > 
> > Though there shouldn't be failed QR_EC transactions, and this gap was
> > efficiently used for catching and learning the SCI_EVT clearing timing
> > compliance issues, we need to fix this as we are not fully compatible
> > with all platforms/Windows to handle SCI_EVT clearing timing correctly.
> > Fixing this gives the EC driver the chances to recover from a state machine
> > failure.
> > 
> > So this patch fixes this issue. When nr_pending_queries drops to 0, it
> > clears EC_FLAGS_QUERY_PENDING at the proper position for different modes in
> > order to ensure that the SCI_EVT handling can proceed.
> > 
> > In order to be clearer for future ec_event_clearing modes, all checks in
> > this patch are written in the inclusive style, not the exclusive style.
> > 
> > Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
> > Signed-off-by: Lv Zheng <lv.zheng@intel.com>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > 
> > diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> > index 79817ce164c1..9d4761d2f6b7 100644
> > --- a/drivers/acpi/ec.c
> > +++ b/drivers/acpi/ec.c
> > @@ -512,7 +512,8 @@ static void advance_transaction(struct acpi_ec *ec)
> >  	 */
> >  	if (!t || !(t->flags & ACPI_EC_COMMAND_POLL)) {
> >  		if (ec_event_clearing == ACPI_EC_EVT_TIMING_EVENT &&
> > -		    test_bit(EC_FLAGS_QUERY_GUARDING, &ec->flags)) {
> > +		    (!ec->nr_pending_queries ||
> > +		     test_bit(EC_FLAGS_QUERY_GUARDING, &ec->flags))) {
> >  			clear_bit(EC_FLAGS_QUERY_GUARDING, &ec->flags);
> >  			acpi_ec_complete_query(ec);
> >  		}
> > @@ -1065,6 +1066,17 @@ static void acpi_ec_event_handler(struct work_struct *work)
> >  		(void)acpi_ec_query(ec, NULL);
> >  		spin_lock_irqsave(&ec->lock, flags);
> >  		ec->nr_pending_queries--;
> > +		/*
> > +		 * Before exit, make sure that this work item can be
> > +		 * scheduled again. There might be QR_EC failures, leaving
> > +		 * EC_FLAGS_QUERY_PENDING uncleared and preventing this work
> > +		 * item from being scheduled again.
> > +		 */
> > +		if (!ec->nr_pending_queries) {
> > +			if (ec_event_clearing == ACPI_EC_EVT_TIMING_STATUS ||
> > +			    ec_event_clearing == ACPI_EC_EVT_TIMING_QUERY)
> > +				acpi_ec_complete_query(ec);
> > +		}
> >  	}
> >  	spin_unlock_irqrestore(&ec->lock, flags);
> >