Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754530AbbBFNnn (ORCPT ); Fri, 6 Feb 2015 08:43:43 -0500 Received: from hofr.at ([212.69.189.236]:36562 "EHLO mail.hofr.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751814AbbBFNnl (ORCPT ); Fri, 6 Feb 2015 08:43:41 -0500 Date: Fri, 6 Feb 2015 14:43:34 +0100 From: Nicholas Mc Guire To: Tormod Volden Cc: Scot Doyle , Nicholas Mc Guire , Thomas Winischhofer , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC] video: fbdev: sis: condition with no effect Message-ID: <20150206134334.GA32696@opentech.at> References: <1423049774-16305-1-git-send-email-hofrat@osadl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3798 Lines: 82 On Thu, 05 Feb 2015, Tormod Volden wrote: > On Thu, Feb 5, 2015 at 9:45 PM, Scot Doyle wrote: > > On Wed, 4 Feb 2015, Nicholas Mc Guire wrote: > >> The if and the else branch code are identical - so the condition has no > >> effect on the effective code - this patch removes the condition and the > >> duplicated code. > >> > >> Signed-off-by: Nicholas Mc Guire > >> --- > >> > >> This code has been in here since commit 544393fe584d ("sisfb update") so I guess it is > >> safe to simply remove the duplicated code if nobody noticed for 10 years. > >> > >> Note that the code is not really CodingStyle compliant - the lines inserted were formatted > >> to satisfy the coding style but I'm unsure if it is not better to leave it in the > >> old format. > >> > >> Patch was only compile tested with x86_64_defconfig + > >> CONFIG_FB_SIS=m, CONFIG_FB_SIS_300=y, CONFIG_FB_SIS_315=y > >> > >> Patch is against 3.19.0-rc7 (localversion-next is -next-20150204) > >> > >> drivers/video/fbdev/sis/init301.c | 9 ++------- > >> 1 file changed, 2 insertions(+), 7 deletions(-) > >> > >> diff --git a/drivers/video/fbdev/sis/init301.c b/drivers/video/fbdev/sis/init301.c > >> index 295e0de..9533a8ab 100644 > >> --- a/drivers/video/fbdev/sis/init301.c > >> +++ b/drivers/video/fbdev/sis/init301.c > >> @@ -7971,13 +7971,8 @@ SiS_SetCHTVReg(struct SiS_Private *SiS_Pr, unsigned short ModeNo, unsigned short > >> } > >> } else { /* ---- PAL ---- */ > >> /* We don't play around with FSCI in PAL mode */ > >> - if(resindex == 0x04) { > >> - SiS_SetCH70xxANDOR(SiS_Pr,0x20,0x00,0xEF); /* loop filter off */ > >> - SiS_SetCH70xxANDOR(SiS_Pr,0x21,0x01,0xFE); /* ACIV on */ > >> - } else { > >> - SiS_SetCH70xxANDOR(SiS_Pr,0x20,0x00,0xEF); /* loop filter off */ > >> - SiS_SetCH70xxANDOR(SiS_Pr,0x21,0x01,0xFE); /* ACIV on */ > >> - } > >> + SiS_SetCH70xxANDOR(SiS_Pr, 0x20, 0x00, 0xEF); /* loop filter off */ > >> + SiS_SetCH70xxANDOR(SiS_Pr, 0x21, 0x01, 0xFE); /* ACIV on */ > >> } > >> > >> #endif /* 300 */ > > > > The code covering the PAL case had this redundancy when it was introduced > > in Linux 2.4.19. > > > > Lines 7934-7981 consider three variables: PAL, overscan, and resindex. > > Given the "#ifdef 0" block, couldn't the current six sections collapse > > into two? One for (!PAL && overscan && resindex==5) and another for the > > rest? > > Are we sure there isn't a typo in one of the duplicate clauses? Or > wrong copy-pasting? Generally I am skeptical to "fixing" code without > understanding what is behind or testing it, and just cosmetically > brush over it. For now at least it is obvious that there is something > wrong. In case (although an unlikely one) someone who understands the > code and knows this chip comes along, he would quickly spot this. > After your "fixups" this will be all forgotten. Additionally it adds > to the impression that this code is being maintained, which is wrong. > > I would understand an argument about annoying compiler warnings and > the like, but in that case I would prefer to #if 0 it instead of > "prettifying" it. > Its actually a static code checker that is fussing at this. The #if 0 case is on my list as well - but thats a different scanner - and thus goes into a separate patch. I agree that it could be a hidden bug - but given that its this way for 10 years I doubt this. thx! hofrat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/