linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: David Cohen <dacohen@gmail.com>
Cc: linux-omap <linux-omap@vger.kernel.org>,
	linux-arm <linux-arm-kernel@lists.infradead.org>,
	Kevin Hilman <khilman@ti.com>, Tony <tony@atomide.com>,
	Paul <paul@pwsan.com>
Subject: Re: [PATCH V3 05/19] OMAP3+: voltage: use IS_ERR_OR_NULL
Date: Sun, 06 Mar 2011 08:15:06 +0530	[thread overview]
Message-ID: <4D72F532.3020909@ti.com> (raw)
In-Reply-To: <AANLkTi=q_ASfvLbZv=D8p3XvuMX8ek3hcEHU5wtfkm7J@mail.gmail.com>

David Cohen wrote, on 03/05/2011 11:06 PM:
[..]
>> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
>> index 53c399f..76bcaee 100644
>> --- a/arch/arm/mach-omap2/voltage.c
>> +++ b/arch/arm/mach-omap2/voltage.c
>> @@ -682,7 +682,7 @@ unsigned long omap_voltage_get_nom_volt(struct voltagedomain *voltdm)
>>   {
>>         struct omap_vdd_info *vdd;
>>
>> -       if (!voltdm || IS_ERR(voltdm)) {
>> +       if (IS_ERR_OR_NULL(voltdm)) {
>
> I have one comment here. voltdm is received as parameter and it's
> already checked by IS_ERR(). Is there any specific reason for that?
yes:
1. omap_voltage_domain_lookup can return ERR_PTR() in certain conditions
2. the !voltdm is coz of the usage of these APIs from external to 
voltage.c (sr, pm, dvfs etc) - it is possible (and has happend) when 
mistakes have been made and NULL pointers passed as voltdm.


> IS_ERR() doesn't suppose to be a macro to check if the pointer is
> valid or not, but to know if there's an invalid value with error code
> in the pointer value. It's useful when you have a function which
> returns a pointer but it can return an error code when it fails.
> Please, note that IS_ERR() won't detect invalid pointers which does
> not represent an error code, so it's not correct to rely on it for
> this purpose.
> IMO, instead of change to IS_ERR_OR_NULL(), you could only remove
> IS_ERR(). The same apply for the other cases.
no, I am not convinced with your argument.

omap_voltage_get_nom_volt(omap_voltage_domain_lookup("me"));
IS_ERR is useful in this case. If I were to remove vdata, 
PTR_ERR(something)== vdata and vdata !=NULL and it will try to 
dereference and crash.

my_dumb_func(){
	struct voltagedomain *vdata = NULL;
	if (cpu_is_omap3630()_) {
		vdata = omap_voltage_domain_lookup("mpu")
	}
	/* forgot to add other cpu types or a else case */
	/* do other things */
	me_volt=omap_voltage_get_nom_volt(vdata);
	/* do things with me_volt */
}

Sorry, but i think the check, even if seems superfluous is sane IMHO. 
even if the above code worked on 3630, it'd fail on o4/3430 without the 
check, it can even crash. and given that we've all seen our fair share 
of developers who develop for one platform without consideration that 
the rest of the world uses others as well... I do feel cases like above 
example might infact be a reality.

[...]

-- 
Regards,
Nishanth Menon

  reply	other threads:[~2011-03-06  2:45 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-05 15:29 [PATCH V3 00/19] OMAP3+: PM: introduce SR class 1.5 Nishanth Menon
2011-03-05 15:29 ` [PATCH V3 01/19] OMAP3: hwmod: add SmartReflex IRQs Nishanth Menon
2011-03-17 14:41   ` Kevin Hilman
2011-07-26 13:11   ` Felipe Balbi
2011-03-05 15:29 ` [PATCH V3 02/19] OMAP3+: voltage: fix build warning Nishanth Menon
2011-03-17 14:49   ` Kevin Hilman
2011-07-26 13:12   ` Felipe Balbi
2011-03-05 15:29 ` [PATCH V3 03/19] OMAP3+: voltage: remove initial voltage Nishanth Menon
2011-03-06 13:37   ` Sergei Shtylyov
2011-03-07  2:52     ` Nishanth Menon
2011-03-07 16:23       ` Sergei Shtylyov
2011-03-08  1:52         ` Nishanth Menon
2011-07-26 13:17           ` Felipe Balbi
2011-03-17 14:53   ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 04/19] OMAP3+: voltage: remove spurious pr_notice for debugfs Nishanth Menon
2011-03-17 14:55   ` Kevin Hilman
2011-07-26 13:18   ` Felipe Balbi
2011-03-05 15:29 ` [PATCH V3 05/19] OMAP3+: voltage: use IS_ERR_OR_NULL Nishanth Menon
2011-03-05 17:36   ` David Cohen
2011-03-06  2:45     ` Nishanth Menon [this message]
2011-03-06  8:18       ` Russell King - ARM Linux
2011-03-07  2:56         ` Nishanth Menon
2011-07-26 13:19   ` Felipe Balbi
2011-03-05 15:29 ` [PATCH V3 06/19] OMAP3+: voltage: use volt_data pointer instead values Nishanth Menon
2011-03-17 17:09   ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 07/19] OMAP3+: voltage: add transdone APIs Nishanth Menon
2011-03-17 17:14   ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 08/19] OMAP3+: SR: make notify independent of class Nishanth Menon
2011-03-17 17:18   ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 09/19] OMAP3+: SR: disable interrupt by default Nishanth Menon
2011-03-17 17:19   ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 10/19] OMAP3+: SR: enable/disable SR only on need Nishanth Menon
2011-03-17 17:20   ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 11/19] OMAP3+: SR: fix cosmetic indentation Nishanth Menon
2011-03-17 17:21   ` Kevin Hilman
2011-03-17 17:43     ` Aaro Koskinen
2011-03-17 20:02       ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 12/19] OMAP3+: SR: introduce class start,stop and priv data Nishanth Menon
2011-03-17 17:23   ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 13/19] OMAP3+: SR: Reuse sr_[start|stop]_vddautocomp functions Nishanth Menon
2011-03-07 14:40   ` Jarkko Nikula
2011-03-17 17:25   ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 14/19] OMAP3+: SR: introduce notifiers flags Nishanth Menon
2011-03-17 17:28   ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 15/19] OMAP3+: SR: introduce notifier_control Nishanth Menon
2011-03-17 17:35   ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 16/19] OMAP3+: SR: disable spamming interrupts Nishanth Menon
2011-03-05 15:29 ` [PATCH V3 17/19] OMAP3+: SR: make enable path use volt_data pointer Nishanth Menon
2011-03-17 17:41   ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 18/19] OMAP3630+: SR: add support for class 1.5 Nishanth Menon
2011-03-17 19:57   ` Kevin Hilman
2011-03-05 15:29 ` [PATCH V3 19/19] OMAP3430: SR: class3: restrict CPU to run on Nishanth Menon
2011-03-17 19:58   ` Kevin Hilman

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=4D72F532.3020909@ti.com \
    --to=nm@ti.com \
    --cc=dacohen@gmail.com \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=tony@atomide.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).