[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130128095754.GA23134@avionic-0098.adnet.avionic-design.de>
Date: Mon, 28 Jan 2013 10:57:54 +0100
From: Thierry Reding <thierry.reding@...onic-design.de>
To: Florian Vaussard <florian.vaussard@...l.ch>
Cc: Peter Ujfalusi <peter.ujfalusi@...com>,
Bryan Wu <cooloney@...il.com>,
Richard Purdie <rpurdie@...ys.net>, linux-leds@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] pwm: Add pwm_cansleep() as exported API to users
On Mon, Jan 28, 2013 at 10:36:07AM +0100, Florian Vaussard wrote:
> Hello,
>
> Le 28/01/2013 09:45, Peter Ujfalusi a écrit :
> >hi Thierry,
> >
> >On 01/26/2013 06:40 AM, Thierry Reding wrote:
[...]
> >>>+{
> >>>+ return pwm->chip->can_sleep;
> >>>+}
> >>>+EXPORT_SYMBOL_GPL(pwm_cansleep);
> >>
> >>Would it make sense to check for NULL pointers here? I guess that
> >>passing NULL into the function could be considered a programming error
> >>and an oops would be okay, but in that case there's no point in making
> >>the function return an int. Also see my next comment.
> >
> >While it is unlikely to happen it is better to be safe, something like this
> >will do:
> >
> >return pwm ? pwm->chip->can_sleep : 0;
> >
>
> Ok. And what about:
>
> BUG_ON(pwm == NULL);
> return pwm->chip->can_sleep;
I don't think we need that. In case pwm == NULL, dereferencing it will
oops anyway. So either we make it safe and return an error code, or we
let it oops without explicit BUG_ON().
Thierry
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists