Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935725AbcKJVEm convert rfc822-to-8bit (ORCPT ); Thu, 10 Nov 2016 16:04:42 -0500 Received: from pic75-3-78-194-244-226.fbxo.proxad.net ([78.194.244.226]:55774 "EHLO mail.corsac.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935187AbcKJVEj (ORCPT ); Thu, 10 Nov 2016 16:04:39 -0500 Message-ID: <1478811873.31531.4.camel@corsac.net> Subject: Re: [PATCH] firmware: fix async/manual firmware loading From: Yves-Alexis Perez To: "Luis R. Rodriguez" , Bjorn Andersson Cc: Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , Ming Lei , Johannes Berg , Jouni Malinen , Kees Cook , Jiri Kosina , Jiri Slaby , Tom Gundersen , Kay Sievers , Josh Boyer , Dmitry Torokhov , Andy Lutomirski , Harald Hoyer , Seth Forshee , Daniel Wagner , "4.2+" Date: Thu, 10 Nov 2016 22:04:33 +0100 In-Reply-To: References: <20161030145048.6291-1-corsac@corsac.net> <20161030145048.6291-2-corsac@corsac.net> <20161109203921.GH13978@wotan.suse.de> <20161110155511.GA10806@kroah.com> <20161110185212.GE11179@tuxbot> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Mailer: Evolution 3.22.2-1 Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1390 Lines: 39 On Thu, 2016-11-10 at 11:48 -0800, Luis R. Rodriguez wrote: > > I haven't verified that this particular use case actually worked before, > > but this code works with lower timeout values (e.g. 60 in the fallback > > case), so this looks isolated. > > This is true, but as I noted the broken aspect was when the timeout > was set to the max value. > > > The bug was clearly introduced in v4.0 by: > > > > 68ff2a00dbf5 "firmware_loader: handle timeout via > > wait_for_completion_interruptible_timeout()" > > > > So please add a Fixes: and > > > > Reviewed-by: Bjorn Andersson > > This I agree with, thanks for that, and because of this then: > > Acked-by: Luis R. Rodriguez > > And because of this do recommend it for stable. I would still prefer > at least a new re-submit with the respected tags and a changed commit > log describing the reason for the fix, how the cast is an issue > exactly, and how this is a regression. Hi all, I'm still slightly confused, but I can certainly re-submit it. I've added the CC: stable because I first experienced it on a stable box, but indeed it was during coding a kernel driver so it might not be what's expected in “regression” here. I'll try to collect the tag and rewrite the commit log, then re-submit, hopefully not messing with git send-email this time. Regards, -- Yves-Alexis