LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Thomas Winischhofer <thomas@winischhofer.net>
To: Nicholas Mc Guire <der.herr@hofr.at>
Cc: Tormod Volden <lists.tormod@gmail.com>,
	Scot Doyle <lkml14@scotdoyle.com>,
	Nicholas Mc Guire <hofrat@osadl.org>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] video: fbdev: sis: condition with no effect
Date: Fri, 06 Feb 2015 15:32:37 +0100	[thread overview]
Message-ID: <54D4D085.9020808@winischhofer.net> (raw)
In-Reply-To: <20150206134726.GB32696@opentech.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicholas Mc Guire wrote:
> On Fri, 06 Feb 2015, Thomas Winischhofer wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> 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 <hofrat@osadl.org>
>>>>> ---
>>>>>
>>>>> 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.
>>>
>>> 0.02
>>> Tormod
>>>
>> The code is partly unfinished due to a lack of hardware to test this
>> with. SiS announced SiS+Chrontel 7019 combos at some point but I have
>> never seen one. The code was written based on the Chrontel datasheets,
>> which weren't clear to some extent, and there wasn't ever any test
>> hardware. I don't recall this one exactly, but identical if-else
>> statements mean that one alternative is (assumingly) correct, while the
>> other is uncertain and/or untested. I left such redunant if-statements
>> in the code to remember the conditions and the fact that there is a
>> second alternative.
>>
>> Considering the long time I'd say it's safe to simplify this.
>>
>> A word on other changes I monitored recently: Please bear in mind that
>> with video hardware reading and writing registers is not simple like
>> reading and writing to memory. Sometimes reading causes an effect in the
>> hardware as well (latches, etc), so removing seemingly redundant
>> GetReg/SetReg sequences might actually have an effect.
>>
> thanks for that note - will add that to my checklist of sideffects
> for future patches.
> 
> thx!
> hofrat 
> 

PS: Correction: This code is for the SiS+Chrontel 7005 (not 7019) case,
and there actually WAS hardware. Therefore I also probably tested this,
or this is the remains of a test, and as a consequence it is safe to
simplify/remove.

- --
Thomas Winischhofer
thomas AT winischhofer DOT net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFU1NCFzydIRAktyUcRAkN4AJ9CqUVCbEKyUkSOPvCkRWzKDeaPPQCfdQ4e
ffzCiVCH5Ul7kAXiL/K0RDU=
=tt8c
-----END PGP SIGNATURE-----

  reply	other threads:[~2015-02-06 14:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-04 11:36 Nicholas Mc Guire
2015-02-05 20:45 ` Scot Doyle
2015-02-05 21:27   ` Tormod Volden
2015-02-05 23:37     ` Scot Doyle
2015-02-06  7:00     ` Thomas Winischhofer
2015-02-06 13:47       ` Nicholas Mc Guire
2015-02-06 14:32         ` Thomas Winischhofer [this message]
2015-02-06 13:43     ` Nicholas Mc Guire

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54D4D085.9020808@winischhofer.net \
    --to=thomas@winischhofer.net \
    --cc=der.herr@hofr.at \
    --cc=hofrat@osadl.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lists.tormod@gmail.com \
    --cc=lkml14@scotdoyle.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=tomi.valkeinen@ti.com \
    --subject='Re: [PATCH RFC] video: fbdev: sis: condition with no effect' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).