Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966847AbcCPOYd (ORCPT ); Wed, 16 Mar 2016 10:24:33 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:60378 "EHLO e37.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966816AbcCPOYc (ORCPT ); Wed, 16 Mar 2016 10:24:32 -0400 X-IBM-Helo: d03dlp03.boulder.ibm.com X-IBM-MailFrom: jejb@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org;linux-scsi@vger.kernel.org Message-ID: <1458138262.2421.8.camel@linux.vnet.ibm.com> Subject: Re: [PATCH] qla2xxx: avoid maybe_uninitialized warning From: James Bottomley To: Himanshu Madhani , Arnd Bergmann Cc: Dept-Eng QLA2xxx Upstream , "Martin K. Petersen" , Nicholas Bellinger , Quinn Tran , Alexei Potashnik , Bart Van Assche , Swapnil Nagle , linux-scsi , linux-kernel Date: Wed, 16 Mar 2016 07:24:22 -0700 In-Reply-To: References: <1458078051-529344-1-git-send-email-arnd@arndb.de> <1458078554.2375.97.camel@linux.vnet.ibm.com> <2808565.5VeioJTJAb@wuerfel> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16031614-0025-0000-0000-000022C2DF64 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1192 Lines: 34 On Wed, 2016-03-16 at 14:05 +0000, Himanshu Madhani wrote: > > On 3/16/16, 5:59 AM, "Arnd Bergmann" wrote: > > > On Tuesday 15 March 2016 14:49:14 James Bottomley wrote: > > > On Tue, 2016-03-15 at 22:40 +0100, Arnd Bergmann wrote: > > > > > > > > This slightly rearranges the code to move the second if() block > > > > into the first one, to avoid the warning while retaining the > > > > behavior of the code. > > > > > > I thought our usual policy was to ask someone to fix the compiler > > > when it emitted a spurious warning. > > > > No, the rule is that we shouldn't blindly add initializations to > > the variables when the compiler should have figured it out. > > > > In this case, I wouldn't expect the compiler to ever see through > > the unlikely() macro, and I'm not adding a potentially > > counterproductive initialization, so I see no reason not to apply > > the patch. OK, as long as there's a good reason why the compiler can never be fixed to sort out this case. > I would like to keep unlikely() macro in the code. This patch looks > good. > > Acked-By: Himanshu Madhani Well, OK that's good enough for me. James