[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Julia Lawall]

Function clk_get, defined just below this code, returns ERR_PTR not NULL in
an error case.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
identifier f;
@@
f(...) { ... return ERR_PTR(...); }

@@
identifier r.f, fld;
expression x;
statement S1,S2;
@@
 x = f(...)
 ... when != IS_ERR(x)
(
 if (IS_ERR(x) ||...) S1 else S2
|
*x->fld
)
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>

---
 arch/arm/mach-at91/clock.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
index 9113da6..c9ee6d0 100644
--- a/arch/arm/mach-at91/clock.c
+++ b/arch/arm/mach-at91/clock.c
@@ -224,7 +224,7 @@ void __init at91_clock_associate(const char *id, struct device *dev, const char
 {
 	struct clk *clk = clk_get(NULL, id);
 
-	if (!dev || !clk || !IS_ERR(clk_get(dev, func)))
+	if (!dev || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
 		return;
 
 	clk->function = func;

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Ryan Mallon]

On 01/25/2011 08:55 AM, Julia Lawall wrote:
> Function clk_get, defined just below this code, returns ERR_PTR not NULL in
> an error case.
> 
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // <smpl>
> @r@
> identifier f;
> @@
> f(...) { ... return ERR_PTR(...); }
> 
> @@
> identifier r.f, fld;
> expression x;
> statement S1,S2;
> @@
>  x = f(...)
>  ... when != IS_ERR(x)
> (
>  if (IS_ERR(x) ||...) S1 else S2
> |
> *x->fld
> )
> // </smpl>

I'm always really impressed by this tool :-).

> 
> Signed-off-by: Julia Lawall <julia@diku.dk>
> 
> ---
>  arch/arm/mach-at91/clock.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
> index 9113da6..c9ee6d0 100644
> --- a/arch/arm/mach-at91/clock.c
> +++ b/arch/arm/mach-at91/clock.c
> @@ -224,7 +224,7 @@ void __init at91_clock_associate(const char *id, struct device *dev, const char
>  {
>  	struct clk *clk = clk_get(NULL, id);
>  
> -	if (!dev || !clk || !IS_ERR(clk_get(dev, func)))
> +	if (!dev || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
>  		return;

I think we want:

	if (!dev || !clk || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
		return;

Since it is valid to return a NULL clk, and we don't want to try and
dereference it if that is the case.

We could also probably drop the !IS_ERR(clk_get(dev, func)) check, since
as far as I can tell it is just checking to see if the clock is already
associated, but there is no harm in re-assigning the same values, and
the two assignments in at91_clock_associate are going to be much quicker
than the lookup in clk_get.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Julia Lawall]

On Tue, 25 Jan 2011, Ryan Mallon wrote:

> On 01/25/2011 08:55 AM, Julia Lawall wrote:
> > Function clk_get, defined just below this code, returns ERR_PTR not NULL in
> > an error case.
> > 
> > The semantic match that finds this problem is as follows:
> > (http://coccinelle.lip6.fr/)
> > 
> > // <smpl>
> > @r@
> > identifier f;
> > @@
> > f(...) { ... return ERR_PTR(...); }
> > 
> > @@
> > identifier r.f, fld;
> > expression x;
> > statement S1,S2;
> > @@
> >  x = f(...)
> >  ... when != IS_ERR(x)
> > (
> >  if (IS_ERR(x) ||...) S1 else S2
> > |
> > *x->fld
> > )
> > // </smpl>
> 
> I'm always really impressed by this tool :-).
> 
> > 
> > Signed-off-by: Julia Lawall <julia@diku.dk>
> > 
> > ---
> >  arch/arm/mach-at91/clock.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
> > index 9113da6..c9ee6d0 100644
> > --- a/arch/arm/mach-at91/clock.c
> > +++ b/arch/arm/mach-at91/clock.c
> > @@ -224,7 +224,7 @@ void __init at91_clock_associate(const char *id, struct device *dev, const char
> >  {
> >  	struct clk *clk = clk_get(NULL, id);
> >  
> > -	if (!dev || !clk || !IS_ERR(clk_get(dev, func)))
> > +	if (!dev || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
> >  		return;
> 
> I think we want:
> 
> 	if (!dev || !clk || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
> 		return;
> 
> Since it is valid to return a NULL clk, and we don't want to try and
> dereference it if that is the case.

Looking at the given defintion of clk_get, I can't see how that could 
happen:

struct clk *clk_get(struct device *dev, const char *id)
{
        struct clk *clk;

        list_for_each_entry(clk, &clocks, node) {
                if (strcmp(id, clk->name) == 0)
                        return clk;
                if (clk->function && (dev == clk->dev) && strcmp(id, clk->function) == 0)
                        return clk;
        }

        return ERR_PTR(-ENOENT);
}

Both paths to the non-ERR_PTR return dereference clk.

julia

> We could also probably drop the !IS_ERR(clk_get(dev, func)) check, since
> as far as I can tell it is just checking to see if the clock is already
> associated, but there is no harm in re-assigning the same values, and
> the two assignments in at91_clock_associate are going to be much quicker
> than the lookup in clk_get.
> 
> ~Ryan
> 
> -- 
> Bluewater Systems Ltd - ARM Technology Solution Centre
> 
> Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
> ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
> http://www.bluewatersys.com	New Zealand
> Phone: +64 3 3779127		Freecall: Australia 1800 148 751
> Fax:   +64 3 3779135			  USA 1800 261 2934
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Vasiliy Kulikov]

On Mon, Jan 24, 2011 at 21:00 +0100, Julia Lawall wrote:
> On Tue, 25 Jan 2011, Ryan Mallon wrote:
> 
> > On 01/25/2011 08:55 AM, Julia Lawall wrote:
> > > @@ -224,7 +224,7 @@ void __init at91_clock_associate(const char *id, struct device *dev, const char
> > >  {
> > >  	struct clk *clk = clk_get(NULL, id);
> > >  
> > > -	if (!dev || !clk || !IS_ERR(clk_get(dev, func)))
> > > +	if (!dev || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
> > >  		return;
> > 
> > I think we want:
> > 
> > 	if (!dev || !clk || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
> > 		return;
> > 
> > Since it is valid to return a NULL clk, and we don't want to try and
> > dereference it if that is the case.
> 
> Looking at the given defintion of clk_get, I can't see how that could 
> happen:

clk_get() is defined per-architecture, sometimes it is NULL only.

> struct clk *clk_get(struct device *dev, const char *id)
> {
>         struct clk *clk;
> 
>         list_for_each_entry(clk, &clocks, node) {
>                 if (strcmp(id, clk->name) == 0)
>                         return clk;
>                 if (clk->function && (dev == clk->dev) && strcmp(id, clk->function) == 0)
>                         return clk;
>         }
> 
>         return ERR_PTR(-ENOENT);
> }
> 
> Both paths to the non-ERR_PTR return dereference clk.
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Vasiliy

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Julia Lawall]

On Mon, 24 Jan 2011, Vasiliy Kulikov wrote:

> On Mon, Jan 24, 2011 at 21:00 +0100, Julia Lawall wrote:
> > On Tue, 25 Jan 2011, Ryan Mallon wrote:
> > 
> > > On 01/25/2011 08:55 AM, Julia Lawall wrote:
> > > > @@ -224,7 +224,7 @@ void __init at91_clock_associate(const char *id, struct device *dev, const char
> > > >  {
> > > >  	struct clk *clk = clk_get(NULL, id);
> > > >  
> > > > -	if (!dev || !clk || !IS_ERR(clk_get(dev, func)))
> > > > +	if (!dev || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
> > > >  		return;
> > > 
> > > I think we want:
> > > 
> > > 	if (!dev || !clk || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
> > > 		return;
> > > 
> > > Since it is valid to return a NULL clk, and we don't want to try and
> > > dereference it if that is the case.
> > 
> > Looking at the given defintion of clk_get, I can't see how that could 
> > happen:
> 
> clk_get() is defined per-architecture, sometimes it is NULL only.

In this case there is a definition in the same file, so it doesn't seem 
necessary to worry about possible other ones.  Unless there is some goal 
in the future to remove the local one?

julia

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Vasiliy Kulikov]

On Mon, Jan 24, 2011 at 21:09 +0100, Julia Lawall wrote:
> On Mon, 24 Jan 2011, Vasiliy Kulikov wrote:
> > clk_get() is defined per-architecture, sometimes it is NULL only.
> 
> In this case there is a definition in the same file, so it doesn't seem 
> necessary to worry about possible other ones.  Unless there is some goal 
> in the future to remove the local one?

My oppinion is that even such architecture dependent code written in
architecure indepenent way is highly desirable.  Besides more clean code
it is probably review by smaller group of people, so it is potentially
more buggy.


Thanks,

-- 
Vasiliy

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[walter harms]

Am 24.01.2011 21:09, schrieb Julia Lawall:
> On Mon, 24 Jan 2011, Vasiliy Kulikov wrote:
> 
>> On Mon, Jan 24, 2011 at 21:00 +0100, Julia Lawall wrote:
>>> On Tue, 25 Jan 2011, Ryan Mallon wrote:
>>>
>>>> On 01/25/2011 08:55 AM, Julia Lawall wrote:
>>>>> @@ -224,7 +224,7 @@ void __init at91_clock_associate(const char *id, struct device *dev, const char
>>>>>  {
>>>>>  	struct clk *clk = clk_get(NULL, id);
>>>>>  
>>>>> -	if (!dev || !clk || !IS_ERR(clk_get(dev, func)))
>>>>> +	if (!dev || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
>>>>>  		return;
>>>>
>>>> I think we want:
>>>>
>>>> 	if (!dev || !clk || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
>>>> 		return;
>>>>
>>>> Since it is valid to return a NULL clk, and we don't want to try and
>>>> dereference it if that is the case.
>>>
>>> Looking at the given defintion of clk_get, I can't see how that could 
>>> happen:
>>
>> clk_get() is defined per-architecture, sometimes it is NULL only.
> 
> In this case there is a definition in the same file, so it doesn't seem 
> necessary to worry about possible other ones.  Unless there is some goal 
> in the future to remove the local one?
> 

Would it be more easy to return NULL in the error case of clk_get() instead
of ERR_PTR(-ENOENT) ?

So the default could be return NULL and an architecture depending solution
replacing that.

re,
 wh

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Russell King - ARM Linux]

On Tue, Jan 25, 2011 at 11:33:16AM +0100, walter harms wrote:
> Would it be more easy to return NULL in the error case of clk_get() instead
> of ERR_PTR(-ENOENT) ?
> 
> So the default could be return NULL and an architecture depending solution
> replacing that.

That's not how the API is defined.  The API defines error-pointers to be
errors, everything should be considered valid.  Please don't go down the
route of doing something architecturally different from that.

What if, say, you couldn't return the struct clk because maybe it could
only be controlled by one user?  Returning an EBUSY error pointer would
indicate this condition.  What if the module providing the struct clk
hasn't finished initializing - that's another reason for EBUSY rather
than ENOENT.

Error codes are useful to describe why something failed.  NULL pointers
can't do that.

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[walter harms]

Am 25.01.2011 11:43, schrieb Russell King - ARM Linux:
> On Tue, Jan 25, 2011 at 11:33:16AM +0100, walter harms wrote:
>> Would it be more easy to return NULL in the error case of clk_get() instead
>> of ERR_PTR(-ENOENT) ?
>>
>> So the default could be return NULL and an architecture depending solution
>> replacing that.
> 
> That's not how the API is defined.  The API defines error-pointers to be
> errors, everything should be considered valid.  Please don't go down the
> route of doing something architecturally different from that.
> 
> What if, say, you couldn't return the struct clk because maybe it could
> only be controlled by one user?  Returning an EBUSY error pointer would
> indicate this condition.  What if the module providing the struct clk
> hasn't finished initializing - that's another reason for EBUSY rather
> than ENOENT.
> 
> Error codes are useful to describe why something failed.  NULL pointers
> can't do that.
> 

On Mon, 24 Jan 2011, Vasiliy Kulikov wrote:
> 
...
> clk_get() is defined per-architecture, sometimes it is NULL only.
>

So these is a bug ? They should return -ENOENT ?

The interessting question is: what to do with an error ?

Obviously some architecture can live with NULL, so it is not an critical
error. An the patch shows a code that is simply a return, not even the
user is informed that something did not work as expected.

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Russell King - ARM Linux]

On Tue, Jan 25, 2011 at 12:12:45PM +0100, walter harms wrote:
> Am 25.01.2011 11:43, schrieb Russell King - ARM Linux:
> > On Tue, Jan 25, 2011 at 11:33:16AM +0100, walter harms wrote:
> >> Would it be more easy to return NULL in the error case of clk_get() instead
> >> of ERR_PTR(-ENOENT) ?
> >>
> >> So the default could be return NULL and an architecture depending solution
> >> replacing that.
> > 
> > That's not how the API is defined.  The API defines error-pointers to be
> > errors, everything should be considered valid.  Please don't go down the
> > route of doing something architecturally different from that.
> > 
> > What if, say, you couldn't return the struct clk because maybe it could
> > only be controlled by one user?  Returning an EBUSY error pointer would
> > indicate this condition.  What if the module providing the struct clk
> > hasn't finished initializing - that's another reason for EBUSY rather
> > than ENOENT.
> > 
> > Error codes are useful to describe why something failed.  NULL pointers
> > can't do that.
> > 
> 
> On Mon, 24 Jan 2011, Vasiliy Kulikov wrote:
> > 
> ...
> > clk_get() is defined per-architecture, sometimes it is NULL only.
> >
> 
> So these is a bug ? They should return -ENOENT ?

You're stuck in "NULL is an error" mode.  struct clk * is a cookie which
only the clk API implementation understands.  It must not be treated as
anything different by drivers.  The only defined values for drivers are
error pointer codes which translate to errors.  Everything else, drivers
must assume is valid.  Drivers are not allowed to dereference struct clk.

It is for the clk API to interpret the struct clk * cookie as it sees fit.

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Julia Lawall]

On Tue, 25 Jan 2011, walter harms wrote:

> 
> 
> Am 25.01.2011 11:43, schrieb Russell King - ARM Linux:
> > On Tue, Jan 25, 2011 at 11:33:16AM +0100, walter harms wrote:
> >> Would it be more easy to return NULL in the error case of clk_get() instead
> >> of ERR_PTR(-ENOENT) ?
> >>
> >> So the default could be return NULL and an architecture depending solution
> >> replacing that.
> > 
> > That's not how the API is defined.  The API defines error-pointers to be
> > errors, everything should be considered valid.  Please don't go down the
> > route of doing something architecturally different from that.
> > 
> > What if, say, you couldn't return the struct clk because maybe it could
> > only be controlled by one user?  Returning an EBUSY error pointer would
> > indicate this condition.  What if the module providing the struct clk
> > hasn't finished initializing - that's another reason for EBUSY rather
> > than ENOENT.
> > 
> > Error codes are useful to describe why something failed.  NULL pointers
> > can't do that.
> > 
> 
> On Mon, 24 Jan 2011, Vasiliy Kulikov wrote:
> > 
> ...
> > clk_get() is defined per-architecture, sometimes it is NULL only.
> >
> 
> So these is a bug ? They should return -ENOENT ?
> 
> The interessting question is: what to do with an error ?
> 
> Obviously some architecture can live with NULL, so it is not an critical
> error. An the patch shows a code that is simply a return, not even the
> user is informed that something did not work as expected.
> 
> From that point of view i would like question if it is useful to have
> a "detailed" error instead of just returning NULL.

Somewhat unrelatedly, I often run into code where error handling code is 
needed, but not present, and the function returns void, so nothing is 
provided for propagating the error further.  I generally consider these 
cases to be beyond my expertise to fix...

julia

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Russell King - ARM Linux]

On Tue, Jan 25, 2011 at 12:18:40PM +0100, Julia Lawall wrote:
> On Tue, 25 Jan 2011, walter harms wrote:
> > So these is a bug ? They should return -ENOENT ?
> > 
> > The interessting question is: what to do with an error ?
> > 
> > Obviously some architecture can live with NULL, so it is not an critical
> > error. An the patch shows a code that is simply a return, not even the
> > user is informed that something did not work as expected.
> > 
> > From that point of view i would like question if it is useful to have
> > a "detailed" error instead of just returning NULL.
> 
> Somewhat unrelatedly, I often run into code where error handling code is 
> needed, but not present, and the function returns void, so nothing is 
> provided for propagating the error further.  I generally consider these 
> cases to be beyond my expertise to fix...

That is a pain, but so is returning NULL in error conditions.  If you've
got several layers of nesting, and every level returns NULL on error,
it's an awful lot of debugging to find out _why_ a failure happened.

With error codes, it narrows down the number of places which could have
returned that error code, and as error codes can be descriptive, it
turns it into an "oh, I forgot about doing X" or "it's failing *there*"
rather than a puzzle.

The only place where it really makes sense to return NULL is with memory
allocators.  NULL is an accepted value for meaning "I couldn't allocate
memory" as its not a useful pointer value.

The alternative is to have an API like:

	struct clk *clk_get(int *error, ...)
or
	int clk_get(struct clk **, ...)

but that then leads to _additional_ errors made by driver authors and by
implementations - you can no longer guarantee that *error will always be
initialized, and this is why the whole ERR_PTR/PTR_ERR/IS_ERR stuff was
implemented.  The kernel used to have such things in it and they were
buggy.

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Julia Lawall]

On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:

> On Tue, Jan 25, 2011 at 12:18:40PM +0100, Julia Lawall wrote:
> > On Tue, 25 Jan 2011, walter harms wrote:
> > > So these is a bug ? They should return -ENOENT ?
> > > 
> > > The interessting question is: what to do with an error ?
> > > 
> > > Obviously some architecture can live with NULL, so it is not an critical
> > > error. An the patch shows a code that is simply a return, not even the
> > > user is informed that something did not work as expected.
> > > 
> > > From that point of view i would like question if it is useful to have
> > > a "detailed" error instead of just returning NULL.
> > 
> > Somewhat unrelatedly, I often run into code where error handling code is 
> > needed, but not present, and the function returns void, so nothing is 
> > provided for propagating the error further.  I generally consider these 
> > cases to be beyond my expertise to fix...
> 
> That is a pain, but so is returning NULL in error conditions.  If you've
> got several layers of nesting, and every level returns NULL on error,
> it's an awful lot of debugging to find out _why_ a failure happened.
> 
> With error codes, it narrows down the number of places which could have
> returned that error code, and as error codes can be descriptive, it
> turns it into an "oh, I forgot about doing X" or "it's failing *there*"
> rather than a puzzle.
> 
> The only place where it really makes sense to return NULL is with memory
> allocators.  NULL is an accepted value for meaning "I couldn't allocate
> memory" as its not a useful pointer value.
> 
> The alternative is to have an API like:
> 
> 	struct clk *clk_get(int *error, ...)
> or
> 	int clk_get(struct clk **, ...)
> 
> but that then leads to _additional_ errors made by driver authors and by
> implementations - you can no longer guarantee that *error will always be
> initialized, and this is why the whole ERR_PTR/PTR_ERR/IS_ERR stuff was
> implemented.  The kernel used to have such things in it and they were
> buggy.

I agree that error codes are very useful.  The problem is rather how to 
propagate any sort of error indicator, whether ERR_PTR, NULL, an negative 
integer, etc.

julia

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Ryan Mallon]

On 01/25/2011 09:05 AM, Vasiliy Kulikov wrote:
> On Mon, Jan 24, 2011 at 21:00 +0100, Julia Lawall wrote:
>> On Tue, 25 Jan 2011, Ryan Mallon wrote:
>>
>>> On 01/25/2011 08:55 AM, Julia Lawall wrote:
>>>> @@ -224,7 +224,7 @@ void __init at91_clock_associate(const char *id, struct device *dev, const char
>>>>  {
>>>>  	struct clk *clk = clk_get(NULL, id);
>>>>  
>>>> -	if (!dev || !clk || !IS_ERR(clk_get(dev, func)))
>>>> +	if (!dev || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
>>>>  		return;
>>>
>>> I think we want:
>>>
>>> 	if (!dev || !clk || IS_ERR(clk) || !IS_ERR(clk_get(dev, func)))
>>> 		return;
>>>
>>> Since it is valid to return a NULL clk, and we don't want to try and
>>> dereference it if that is the case.
>>
>> Looking at the given defintion of clk_get, I can't see how that could 
>> happen:
> 
> clk_get() is defined per-architecture, sometimes it is NULL only.

Julia is correct. Some architectures can return NULL from clk_get, but I
didn't check the at91 before posting :-/. If we can't return NULL from
clk_get then we shouldn't bother checking for it. I do think we should
drop the !IS_ERR(clk_get(dev, func)) check though.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Julia Lawall]

> Julia is correct. Some architectures can return NULL from clk_get, but I
> didn't check the at91 before posting :-/. If we can't return NULL from
> clk_get then we shouldn't bother checking for it. I do think we should
> drop the !IS_ERR(clk_get(dev, func)) check though.

It seems a bit subtle, because the clk manipulated by clk_get in the call 
of clk_get(dev, func) is not necessarily the same as the one in 
clock_associate.  But perhaps this is the only possibility in practice?

julia

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Ryan Mallon]

On 01/25/2011 09:28 AM, Julia Lawall wrote:
>> Julia is correct. Some architectures can return NULL from clk_get, but I
>> didn't check the at91 before posting :-/. If we can't return NULL from
>> clk_get then we shouldn't bother checking for it. I do think we should
>> drop the !IS_ERR(clk_get(dev, func)) check though.
> 
> It seems a bit subtle, because the clk manipulated by clk_get in the call 
> of clk_get(dev, func) is not necessarily the same as the one in 
> clock_associate.  But perhaps this is the only possibility in practice?

Not sure I follow. The at91 clk_get does not modify the clk. In
at91_clock_associate we have:

	clk->function = func;
	clk->dev = dev;

and in clk_get we have:

	if (clk->function && (dev == clk->dev) &&
		strcmp(id, clk->function) == 0)
            return clk;

So at91_clock_associate sets the function for a clock, and clk_get
returns clocks based on the function association if the name lookup
fails. The only caveat to this is that the the clock function name
(clk->function) is not the same as any others clock's clk->name.

The !IS_ERR(clk_get(dev, func)) check in at91_clock_associate just
appears to check that the clock is not already associated with the given
function. We don't really need this check because we are just making the
same assignment anyway.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Julia Lawall]

On Tue, 25 Jan 2011, Ryan Mallon wrote:

> On 01/25/2011 09:28 AM, Julia Lawall wrote:
> >> Julia is correct. Some architectures can return NULL from clk_get, but I
> >> didn't check the at91 before posting :-/. If we can't return NULL from
> >> clk_get then we shouldn't bother checking for it. I do think we should
> >> drop the !IS_ERR(clk_get(dev, func)) check though.
> > 
> > It seems a bit subtle, because the clk manipulated by clk_get in the call 
> > of clk_get(dev, func) is not necessarily the same as the one in 
> > clock_associate.  But perhaps this is the only possibility in practice?
> 
> Not sure I follow. The at91 clk_get does not modify the clk. In
> at91_clock_associate we have:
> 
> 	clk->function = func;
> 	clk->dev = dev;
> 
> and in clk_get we have:
> 
> 	if (clk->function && (dev == clk->dev) &&
> 		strcmp(id, clk->function) == 0)
>             return clk;
> 
> So at91_clock_associate sets the function for a clock, and clk_get
> returns clocks based on the function association if the name lookup
> fails. The only caveat to this is that the the clock function name
> (clk->function) is not the same as any others clock's clk->name.

Right, that was what I was worried about.  That one would find the same 
information already present but somewhere else.  But perhaps it can't 
happen, or it doesn't matter if it does?

julia

> The !IS_ERR(clk_get(dev, func)) check in at91_clock_associate just
> appears to check that the clock is not already associated with the given
> function. We don't really need this check because we are just making the
> same assignment anyway.
> 
> ~Ryan
> 
> -- 
> Bluewater Systems Ltd - ARM Technology Solution Centre
> 
> Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
> ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
> http://www.bluewatersys.com	New Zealand
> Phone: +64 3 3779127		Freecall: Australia 1800 148 751
> Fax:   +64 3 3779135			  USA 1800 261 2934
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Ryan Mallon]

On 01/25/2011 10:01 AM, Julia Lawall wrote:
> On Tue, 25 Jan 2011, Ryan Mallon wrote:
> 
>> On 01/25/2011 09:28 AM, Julia Lawall wrote:
>>>> Julia is correct. Some architectures can return NULL from clk_get, but I
>>>> didn't check the at91 before posting :-/. If we can't return NULL from
>>>> clk_get then we shouldn't bother checking for it. I do think we should
>>>> drop the !IS_ERR(clk_get(dev, func)) check though.
>>>
>>> It seems a bit subtle, because the clk manipulated by clk_get in the call 
>>> of clk_get(dev, func) is not necessarily the same as the one in 
>>> clock_associate.  But perhaps this is the only possibility in practice?
>>
>> Not sure I follow. The at91 clk_get does not modify the clk. In
>> at91_clock_associate we have:
>>
>> 	clk->function = func;
>> 	clk->dev = dev;
>>
>> and in clk_get we have:
>>
>> 	if (clk->function && (dev == clk->dev) &&
>> 		strcmp(id, clk->function) == 0)
>>             return clk;
>>
>> So at91_clock_associate sets the function for a clock, and clk_get
>> returns clocks based on the function association if the name lookup
>> fails. The only caveat to this is that the the clock function name
>> (clk->function) is not the same as any others clock's clk->name.
> 
> Right, that was what I was worried about.  That one would find the same 
> information already present but somewhere else.  But perhaps it can't 
> happen, or it doesn't matter if it does?

I think that users are expected to ensure that clock names and clock
function names do not overlap.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Julia Lawall]

On Tue, 25 Jan 2011, Ryan Mallon wrote:

> On 01/25/2011 10:01 AM, Julia Lawall wrote:
> > On Tue, 25 Jan 2011, Ryan Mallon wrote:
> > 
> >> On 01/25/2011 09:28 AM, Julia Lawall wrote:
> >>>> Julia is correct. Some architectures can return NULL from clk_get, but I
> >>>> didn't check the at91 before posting :-/. If we can't return NULL from
> >>>> clk_get then we shouldn't bother checking for it. I do think we should
> >>>> drop the !IS_ERR(clk_get(dev, func)) check though.
> >>>
> >>> It seems a bit subtle, because the clk manipulated by clk_get in the call 
> >>> of clk_get(dev, func) is not necessarily the same as the one in 
> >>> clock_associate.  But perhaps this is the only possibility in practice?
> >>
> >> Not sure I follow. The at91 clk_get does not modify the clk. In
> >> at91_clock_associate we have:
> >>
> >> 	clk->function = func;
> >> 	clk->dev = dev;
> >>
> >> and in clk_get we have:
> >>
> >> 	if (clk->function && (dev == clk->dev) &&
> >> 		strcmp(id, clk->function) == 0)
> >>             return clk;
> >>
> >> So at91_clock_associate sets the function for a clock, and clk_get
> >> returns clocks based on the function association if the name lookup
> >> fails. The only caveat to this is that the the clock function name
> >> (clk->function) is not the same as any others clock's clk->name.
> > 
> > Right, that was what I was worried about.  That one would find the same 
> > information already present but somewhere else.  But perhaps it can't 
> > happen, or it doesn't matter if it does?
> 
> I think that users are expected to ensure that clock names and clock
> function names do not overlap.

One can't have a clock with a different name but the same device and 
function?

julia

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Ryan Mallon]

On 01/25/2011 10:31 AM, Julia Lawall wrote:
> On Tue, 25 Jan 2011, Ryan Mallon wrote:
> 
>> On 01/25/2011 10:01 AM, Julia Lawall wrote:
>>> On Tue, 25 Jan 2011, Ryan Mallon wrote:
>>>
>>>> On 01/25/2011 09:28 AM, Julia Lawall wrote:
>>>>>> Julia is correct. Some architectures can return NULL from clk_get, but I
>>>>>> didn't check the at91 before posting :-/. If we can't return NULL from
>>>>>> clk_get then we shouldn't bother checking for it. I do think we should
>>>>>> drop the !IS_ERR(clk_get(dev, func)) check though.
>>>>>
>>>>> It seems a bit subtle, because the clk manipulated by clk_get in the call 
>>>>> of clk_get(dev, func) is not necessarily the same as the one in 
>>>>> clock_associate.  But perhaps this is the only possibility in practice?
>>>>
>>>> Not sure I follow. The at91 clk_get does not modify the clk. In
>>>> at91_clock_associate we have:
>>>>
>>>> 	clk->function = func;
>>>> 	clk->dev = dev;
>>>>
>>>> and in clk_get we have:
>>>>
>>>> 	if (clk->function && (dev == clk->dev) &&
>>>> 		strcmp(id, clk->function) == 0)
>>>>             return clk;
>>>>
>>>> So at91_clock_associate sets the function for a clock, and clk_get
>>>> returns clocks based on the function association if the name lookup
>>>> fails. The only caveat to this is that the the clock function name
>>>> (clk->function) is not the same as any others clock's clk->name.
>>>
>>> Right, that was what I was worried about.  That one would find the same 
>>> information already present but somewhere else.  But perhaps it can't 
>>> happen, or it doesn't matter if it does?
>>
>> I think that users are expected to ensure that clock names and clock
>> function names do not overlap.
> 
> One can't have a clock with a different name but the same device and 
> function?

You could, but it would not be helpful. Clock associations are used so
that _different_ devices can have the same function and map to the
correct clock. This is used when there are multiple instances of a
single peripheral. For example, the uart clocks work like this:

	at91_clock_associate("usart1_clk", &pdev->dev, "usart");

so then you can do this in a driver:
	
	uart_clk = clk_get(&pdev->dev, "usart");

Rather than:

	uart_clk = clk_get(NULL, "usart1_clk");

The former will find the correct uart clock for the device. Because each
uart is a separate device the correct clock will be selected for each uart.
	
My point was that there should be no overlap between clk->name and
clk->function otherwise clk_get will not be able to return the correct
clock.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Russell King - ARM Linux]

On Tue, Jan 25, 2011 at 10:51:38AM +1300, Ryan Mallon wrote:
> You could, but it would not be helpful. Clock associations are used so
> that _different_ devices can have the same function and map to the
> correct clock. This is used when there are multiple instances of a
> single peripheral. For example, the uart clocks work like this:
> 
> 	at91_clock_associate("usart1_clk", &pdev->dev, "usart");
> 
> so then you can do this in a driver:
> 	
> 	uart_clk = clk_get(&pdev->dev, "usart");
> 
> Rather than:
> 
> 	uart_clk = clk_get(NULL, "usart1_clk");
> 
> The former will find the correct uart clock for the device. Because each
> uart is a separate device the correct clock will be selected for each uart.
> 	
> My point was that there should be no overlap between clk->name and
> clk->function otherwise clk_get will not be able to return the correct
> clock.

It would be nice if AT91 could switch over to using clkdev at some
point, which greatly helps with associating struct clk's with their
device/function names - and reduces the amount of "different" code.

You can then use clk_add_alias() to create aliases of an existing
clock.

Looking at your clk_get(), I think one way to do this would be, in
clk_register():

	struct clk_lookup *cl;

	/* create function-only entry */
	cl = clkdev_alloc(clk, clk->name, NULL);
	if (!cl)
		return -ENOMEM;
	clkdev_add(cl);

	/* not sure if you need this? */
	if (clk->dev && clk->function) {
		cl = clkdev_alloc(clk, clk->function, "%s", dev_name(clk->dev));
		if (!cl)
			return -ENOMEM;
		clkdev_add(cl);
	}

at91_clock_associate() becomes:

	err = clk_add_alias(func, dev_name(dev), id, NULL);
	return err;

Although maybe in the long run see about removing at91_clock_associate()
entirely as its just a wrapper.

The only requirement there is that 'dev' in each case is a registered
device, otherwise dev_name() won't work.

You can then use the generic clk_get()/clk_put() which clkdev provides.

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Jean-Christophe PLAGNIOL-VILLARD]

On 23:23 Mon 24 Jan     , Russell King - ARM Linux wrote:
> On Tue, Jan 25, 2011 at 10:51:38AM +1300, Ryan Mallon wrote:
> > You could, but it would not be helpful. Clock associations are used so
> > that _different_ devices can have the same function and map to the
> > correct clock. This is used when there are multiple instances of a
> > single peripheral. For example, the uart clocks work like this:
> > 
> > 	at91_clock_associate("usart1_clk", &pdev->dev, "usart");
> > 
> > so then you can do this in a driver:
> > 	
> > 	uart_clk = clk_get(&pdev->dev, "usart");
> > 
> > Rather than:
> > 
> > 	uart_clk = clk_get(NULL, "usart1_clk");
> > 
> > The former will find the correct uart clock for the device. Because each
> > uart is a separate device the correct clock will be selected for each uart.
> > 	
> > My point was that there should be no overlap between clk->name and
> > clk->function otherwise clk_get will not be able to return the correct
> > clock.
> 
> It would be nice if AT91 could switch over to using clkdev at some
> point, which greatly helps with associating struct clk's with their
> device/function names - and reduces the amount of "different" code.
I working on it that's was one of the reason I move clkdev to drivers
as AT91 and AVR32 need to switch

Best Regards,
J.

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Julia Lawall]

On Tue, 25 Jan 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:

> On 23:23 Mon 24 Jan     , Russell King - ARM Linux wrote:
> > On Tue, Jan 25, 2011 at 10:51:38AM +1300, Ryan Mallon wrote:
> > > You could, but it would not be helpful. Clock associations are used so
> > > that _different_ devices can have the same function and map to the
> > > correct clock. This is used when there are multiple instances of a
> > > single peripheral. For example, the uart clocks work like this:
> > > 
> > > 	at91_clock_associate("usart1_clk", &pdev->dev, "usart");
> > > 
> > > so then you can do this in a driver:
> > > 	
> > > 	uart_clk = clk_get(&pdev->dev, "usart");
> > > 
> > > Rather than:
> > > 
> > > 	uart_clk = clk_get(NULL, "usart1_clk");
> > > 
> > > The former will find the correct uart clock for the device. Because each
> > > uart is a separate device the correct clock will be selected for each uart.
> > > 	
> > > My point was that there should be no overlap between clk->name and
> > > clk->function otherwise clk_get will not be able to return the correct
> > > clock.
> > 
> > It would be nice if AT91 could switch over to using clkdev at some
> > point, which greatly helps with associating struct clk's with their
> > device/function names - and reduces the amount of "different" code.
> I working on it that's was one of the reason I move clkdev to drivers
> as AT91 and AVR32 need to switch

Shall I just leave the patch as is then?

julia

[PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test

[Jean-Christophe PLAGNIOL-VILLARD]

On 07:12 Tue 25 Jan     , Julia Lawall wrote:
> On Tue, 25 Jan 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 
> > On 23:23 Mon 24 Jan     , Russell King - ARM Linux wrote:
> > > On Tue, Jan 25, 2011 at 10:51:38AM +1300, Ryan Mallon wrote:
> > > > You could, but it would not be helpful. Clock associations are used so
> > > > that _different_ devices can have the same function and map to the
> > > > correct clock. This is used when there are multiple instances of a
> > > > single peripheral. For example, the uart clocks work like this:
> > > > 
> > > > 	at91_clock_associate("usart1_clk", &pdev->dev, "usart");
> > > > 
> > > > so then you can do this in a driver:
> > > > 	
> > > > 	uart_clk = clk_get(&pdev->dev, "usart");
> > > > 
> > > > Rather than:
> > > > 
> > > > 	uart_clk = clk_get(NULL, "usart1_clk");
> > > > 
> > > > The former will find the correct uart clock for the device. Because each
> > > > uart is a separate device the correct clock will be selected for each uart.
> > > > 	
> > > > My point was that there should be no overlap between clk->name and
> > > > clk->function otherwise clk_get will not be able to return the correct
> > > > clock.
> > > 
> > > It would be nice if AT91 could switch over to using clkdev at some
> > > point, which greatly helps with associating struct clk's with their
> > > device/function names - and reduces the amount of "different" code.
> > I working on it that's was one of the reason I move clkdev to drivers
> > as AT91 and AVR32 need to switch
> 
> Shall I just leave the patch as is then?
I'll try to send a patch before chinese new year

Best Regards,
J.

[PATCH 4/4] arch/arm/mach-omap2/smartreflex.c: Add missing IS_ERR test

[Julia Lawall]

Function _sr_lookup, defined in the same file, returns ERR_PTR not NULL in
an error case.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
identifier f;
@@
f(...) { ... return ERR_PTR(...); }

@@
identifier r.f, fld;
expression x;
statement S1,S2;
@@
 x = f(...)
 ... when != IS_ERR(x)
(
 if (IS_ERR(x) ||...) S1 else S2
|
*x->fld
)
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>

---
 arch/arm/mach-omap2/smartreflex.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index 77ecebf..d7deadf 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -966,7 +966,7 @@ static int __devexit omap_sr_remove(struct platform_device *pdev)
 	}
 
 	sr_info = _sr_lookup(pdata->voltdm);
-	if (!sr_info) {
+	if (IS_ERR(sr_info)) {
 		dev_warn(&pdev->dev, "%s: omap_sr struct not found\n",
 			__func__);
 		return -EINVAL;

[PATCH 4/4] arch/arm/mach-omap2/smartreflex.c: Add missing IS_ERR test

[Kevin Hilman]

Julia Lawall <julia@diku.dk> writes:

> Function _sr_lookup, defined in the same file, returns ERR_PTR not NULL in
> an error case.

Thanks, will queue this via the OMAP tree for 2.6.38-rc.

Kevin

> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @r@
> identifier f;
> @@
> f(...) { ... return ERR_PTR(...); }
>
> @@
> identifier r.f, fld;
> expression x;
> statement S1,S2;
> @@
>  x = f(...)
>  ... when != IS_ERR(x)
> (
>  if (IS_ERR(x) ||...) S1 else S2
> |
> *x->fld
> )
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
>
> ---
>  arch/arm/mach-omap2/smartreflex.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
> index 77ecebf..d7deadf 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -966,7 +966,7 @@ static int __devexit omap_sr_remove(struct platform_device *pdev)
>  	}
>  
>  	sr_info = _sr_lookup(pdata->voltdm);
> -	if (!sr_info) {
> +	if (IS_ERR(sr_info)) {
>  		dev_warn(&pdev->dev, "%s: omap_sr struct not found\n",
>  			__func__);
>  		return -EINVAL;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/