From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RESEND 6/6] clk: s5p-g2d: Fix incorrect usage of IS_ERR_OR_NULL
Date: Thu, 3 Jan 2013 11:21:02 +0000 [thread overview]
Message-ID: <20130103112102.GM2631@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20130103111040.GD7247@mwanda>
On Thu, Jan 03, 2013 at 02:10:40PM +0300, Dan Carpenter wrote:
> Come on... Don't say we haven't read comment. Obviously, the first
> thing we did was read that comment. I've read it many times at this
> point and I still think we should add in a bit which says:
So where does it give you in that comment permission to treat NULL any
differently to any other non-IS_ERR() return value?
It is very clear: values where IS_ERR() is true are considered errors.
Everything else is considered valid.
> "NOTE: Drivers should treat the return value as an opaque cookie
> and not dereference it. NULL returns don't imply an error so don't
> use IS_ERR_OR_NULL() to check for errors."
No. The one thing I've learnt through maintaining www.arm.linux.org.uk
is that the more of these kinds of "lets add to documentation" suggestions
you get, the more _unclear_ the documentation becomes, and the more it is
open to bad interpretation, and the more suggestions to add more words you
receive.
Concise documentation is the only way to go. And what we have there today
is concise and to the point. It specifies it very clearly:
* Returns a struct clk corresponding to the clock producer, or
* valid IS_ERR() condition containing errno.
That one sentence gives you all the information you need about it's return
value. It gives you two choices. (1) a return value where IS_ERR() is
true, which is an error, and (2) a return value where IS_ERR() is false,
which is a valid cookie.
Maybe you don't realise, but IS_ERR(NULL) is false. Therefore, this falls
into category (2).
You can't get clearer than that, unless you don't understand the IS_ERR()
and associated macro.
Moreover, it tells you the function to use to check the return value for
errors. IS_ERR(). It doesn't say IS_ERR_OR_NULL(), it says IS_ERR().
All it takes is for people to engage their grey cells and read the
documentation as it stands, rather than trying to weasel their way around
it and invent crap that it doesn't say.
next prev parent reply other threads:[~2013-01-03 11:21 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-18 17:34 [PATCH RESEND 0/6] Remove incorrect usage of IS_ERR_OR_NULL on clk_get Tony Prisk
2012-12-18 17:34 ` [PATCH RESEND 1/6] clk: omap: Fix incorrect usage of IS_ERR_OR_NULL Tony Prisk
2012-12-18 17:34 ` [PATCH RESEND 2/6] clk: exynos: " Tony Prisk
2012-12-18 18:48 ` Dan Carpenter
2012-12-18 17:34 ` [PATCH RESEND 3/6] " Tony Prisk
2012-12-18 18:39 ` Dan Carpenter
2012-12-18 18:52 ` Tony Prisk
2012-12-18 19:03 ` Dan Carpenter
2012-12-18 19:11 ` Tony Prisk
2012-12-18 19:39 ` Tony Prisk
2012-12-18 17:34 ` [PATCH RESEND 4/6] clk: s5p-tv: " Tony Prisk
2013-01-01 19:41 ` Sylwester Nawrocki
2012-12-18 17:34 ` [PATCH RESEND 5/6] clk: s5p-fimc: " Tony Prisk
2012-12-18 17:34 ` [PATCH RESEND 6/6] clk: s5p-g2d: " Tony Prisk
2012-12-22 21:53 ` Sergei Shtylyov
2013-01-01 18:33 ` Sylwester Nawrocki
2013-01-02 5:10 ` Dan Carpenter
2013-01-02 5:31 ` Tony Prisk
2013-01-02 7:29 ` Julia Lawall
2013-01-02 9:28 ` Russell King - ARM Linux
2013-01-03 9:05 ` Dan Carpenter
2013-01-03 9:14 ` Julia Lawall
2013-01-03 10:00 ` Russell King - ARM Linux
2013-01-03 10:00 ` Russell King - ARM Linux
2013-01-03 11:10 ` Dan Carpenter
2013-01-03 11:21 ` Russell King - ARM Linux [this message]
2013-01-03 13:45 ` Dan Carpenter
2013-01-03 13:52 ` Russell King - ARM Linux
2013-01-02 9:26 ` Russell King - ARM Linux
2013-01-02 9:44 ` Julia Lawall
2013-01-02 10:15 ` Russell King - ARM Linux
2013-01-02 23:14 ` Sylwester Nawrocki
2012-12-18 18:42 ` [PATCH RESEND 0/6] Remove incorrect usage of IS_ERR_OR_NULL on clk_get Dan Carpenter
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=20130103112102.GM2631@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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).