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

["gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>]

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);
> >