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@xxxxxxx> > > --- > 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@xxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
