From: Tony Prisk <linux@prisktech.co.nz>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RESEND 6/6] clk: s5p-g2d: Fix incorrect usage of IS_ERR_OR_NULL
Date: Wed, 02 Jan 2013 05:31:53 +0000 [thread overview]
Message-ID: <1357104713.30504.8.camel@gitbox> (raw)
In-Reply-To: <CA+_b7DK2zbBzbCh15ikEAeGP5h-V9gQ_YcX15O-RNvWxCk8Zfg@mail.gmail.com>
On Wed, 2013-01-02 at 08:10 +0300, Dan Carpenter wrote:
> clk_get() returns NULL if CONFIG_HAVE_CLK is disabled.
>
> I told Tony about this but everyone has been gone with end of year
> holidays so it hasn't been addressed.
>
> Tony, please fix it so people don't apply these patches until
> clk_get() is updated to not return NULL. It sucks to have to revert
> patches.
>
> regards,
> dan carpenter
I posted the query to Mike Turquette, linux-kernel and linux-arm-kernel
mailing lists, regarding the return of NULL when HAVE_CLK is undefined.
Short Answer: A return value of NULL is valid and not an error therefore
we should be using IS_ERR, not IS_ERR_OR_NULL on clk_get results.
I see the obvious problem this creates, and asked this question:
If the driver can't operate with a NULL clk, it should use a
IS_ERR_OR_NULL test to test for failure, rather than IS_ERR.
And Russell's answer:
Why should a _consumer_ of a clock care? It is _very_ important that
people get this idea - to a consumer, the struct clk is just an opaque
cookie. The fact that it appears to be a pointer does _not_ mean that
the driver can do any kind of dereferencing on that pointer - it should
never do so.
Thread can be viewed here:
https://lkml.org/lkml/2012/12/20/105
Regards
Tony Prisk
WARNING: multiple messages have this Message-ID (diff)
From: linux@prisktech.co.nz (Tony Prisk)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RESEND 6/6] clk: s5p-g2d: Fix incorrect usage of IS_ERR_OR_NULL
Date: Wed, 02 Jan 2013 18:31:53 +1300 [thread overview]
Message-ID: <1357104713.30504.8.camel@gitbox> (raw)
In-Reply-To: <CA+_b7DK2zbBzbCh15ikEAeGP5h-V9gQ_YcX15O-RNvWxCk8Zfg@mail.gmail.com>
On Wed, 2013-01-02 at 08:10 +0300, Dan Carpenter wrote:
> clk_get() returns NULL if CONFIG_HAVE_CLK is disabled.
>
> I told Tony about this but everyone has been gone with end of year
> holidays so it hasn't been addressed.
>
> Tony, please fix it so people don't apply these patches until
> clk_get() is updated to not return NULL. It sucks to have to revert
> patches.
>
> regards,
> dan carpenter
I posted the query to Mike Turquette, linux-kernel and linux-arm-kernel
mailing lists, regarding the return of NULL when HAVE_CLK is undefined.
Short Answer: A return value of NULL is valid and not an error therefore
we should be using IS_ERR, not IS_ERR_OR_NULL on clk_get results.
I see the obvious problem this creates, and asked this question:
If the driver can't operate with a NULL clk, it should use a
IS_ERR_OR_NULL test to test for failure, rather than IS_ERR.
And Russell's answer:
Why should a _consumer_ of a clock care? It is _very_ important that
people get this idea - to a consumer, the struct clk is just an opaque
cookie. The fact that it appears to be a pointer does _not_ mean that
the driver can do any kind of dereferencing on that pointer - it should
never do so.
Thread can be viewed here:
https://lkml.org/lkml/2012/12/20/105
Regards
Tony Prisk
WARNING: multiple messages have this Message-ID (diff)
From: Tony Prisk <linux@prisktech.co.nz>
To: Dan Carpenter <error27@gmail.com>
Cc: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>,
Sergei Shtylyov <sshtylyov@mvista.com>,
kernel-janitors@vger.kernel.org,
Tomasz Stanislawski <t.stanislaws@samsung.com>,
linux-kernel@vger.kernel.org,
Kyungmin Park <kyungmin.park@samsung.com>,
linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
Subject: Re: [PATCH RESEND 6/6] clk: s5p-g2d: Fix incorrect usage of IS_ERR_OR_NULL
Date: Wed, 02 Jan 2013 18:31:53 +1300 [thread overview]
Message-ID: <1357104713.30504.8.camel@gitbox> (raw)
In-Reply-To: <CA+_b7DK2zbBzbCh15ikEAeGP5h-V9gQ_YcX15O-RNvWxCk8Zfg@mail.gmail.com>
On Wed, 2013-01-02 at 08:10 +0300, Dan Carpenter wrote:
> clk_get() returns NULL if CONFIG_HAVE_CLK is disabled.
>
> I told Tony about this but everyone has been gone with end of year
> holidays so it hasn't been addressed.
>
> Tony, please fix it so people don't apply these patches until
> clk_get() is updated to not return NULL. It sucks to have to revert
> patches.
>
> regards,
> dan carpenter
I posted the query to Mike Turquette, linux-kernel and linux-arm-kernel
mailing lists, regarding the return of NULL when HAVE_CLK is undefined.
Short Answer: A return value of NULL is valid and not an error therefore
we should be using IS_ERR, not IS_ERR_OR_NULL on clk_get results.
I see the obvious problem this creates, and asked this question:
If the driver can't operate with a NULL clk, it should use a
IS_ERR_OR_NULL test to test for failure, rather than IS_ERR.
And Russell's answer:
Why should a _consumer_ of a clock care? It is _very_ important that
people get this idea - to a consumer, the struct clk is just an opaque
cookie. The fact that it appears to be a pointer does _not_ mean that
the driver can do any kind of dereferencing on that pointer - it should
never do so.
Thread can be viewed here:
https://lkml.org/lkml/2012/12/20/105
Regards
Tony Prisk
next prev parent reply other threads:[~2013-01-02 5:31 UTC|newest]
Thread overview: 101+ 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 ` Tony Prisk
2012-12-18 17:34 ` 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 ` Tony Prisk
2012-12-18 17:34 ` Tony Prisk
2012-12-18 17:34 ` [PATCH RESEND 2/6] clk: exynos: " Tony Prisk
2012-12-18 17:34 ` Tony Prisk
2012-12-18 17:34 ` Tony Prisk
2012-12-18 18:48 ` Dan Carpenter
2012-12-18 18:48 ` Dan Carpenter
2012-12-18 18:48 ` Dan Carpenter
2012-12-18 17:34 ` [PATCH RESEND 3/6] " Tony Prisk
2012-12-18 17:34 ` Tony Prisk
2012-12-18 17:34 ` Tony Prisk
2012-12-18 17:34 ` Tony Prisk
2012-12-18 18:39 ` Dan Carpenter
2012-12-18 18:39 ` Dan Carpenter
2012-12-18 18:39 ` Dan Carpenter
2012-12-18 18:52 ` Tony Prisk
2012-12-18 18:52 ` Tony Prisk
2012-12-18 18:52 ` Tony Prisk
2012-12-18 19:03 ` Dan Carpenter
2012-12-18 19:03 ` Dan Carpenter
2012-12-18 19:03 ` Dan Carpenter
2012-12-18 19:03 ` Dan Carpenter
2012-12-18 19:11 ` Tony Prisk
2012-12-18 19:11 ` Tony Prisk
2012-12-18 19:11 ` Tony Prisk
2012-12-18 19:39 ` Tony Prisk
2012-12-18 19:39 ` Tony Prisk
2012-12-18 19:39 ` Tony Prisk
2012-12-18 17:34 ` [PATCH RESEND 4/6] clk: s5p-tv: " Tony Prisk
2012-12-18 17:34 ` Tony Prisk
2012-12-18 17:34 ` Tony Prisk
2013-01-01 19:41 ` Sylwester Nawrocki
2013-01-01 19:41 ` Sylwester Nawrocki
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 ` Tony Prisk
2012-12-18 17:34 ` Tony Prisk
2012-12-18 17:34 ` [PATCH RESEND 6/6] clk: s5p-g2d: " Tony Prisk
2012-12-18 17:34 ` Tony Prisk
2012-12-18 17:34 ` Tony Prisk
2012-12-22 21:53 ` Sergei Shtylyov
2012-12-22 21:53 ` Sergei Shtylyov
2012-12-22 21:53 ` Sergei Shtylyov
2013-01-01 18:33 ` Sylwester Nawrocki
2013-01-01 18:33 ` Sylwester Nawrocki
2013-01-01 18:33 ` Sylwester Nawrocki
2013-01-02 5:10 ` Dan Carpenter
2013-01-02 5:10 ` Dan Carpenter
2013-01-02 5:10 ` Dan Carpenter
2013-01-02 5:31 ` Tony Prisk [this message]
2013-01-02 5:31 ` Tony Prisk
2013-01-02 5:31 ` Tony Prisk
2013-01-02 7:29 ` Julia Lawall
2013-01-02 7:29 ` Julia Lawall
2013-01-02 7:29 ` Julia Lawall
2013-01-02 9:28 ` Russell King - ARM Linux
2013-01-02 9:28 ` Russell King - ARM Linux
2013-01-02 9:28 ` Russell King - ARM Linux
2013-01-03 9:05 ` Dan Carpenter
2013-01-03 9:05 ` Dan Carpenter
2013-01-03 9:05 ` Dan Carpenter
2013-01-03 9:14 ` Julia Lawall
2013-01-03 9:14 ` Julia Lawall
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 10:00 ` Russell King - ARM Linux
2013-01-03 10:00 ` Russell King - ARM Linux
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:10 ` Dan Carpenter
2013-01-03 11:10 ` Dan Carpenter
2013-01-03 11:21 ` Russell King - ARM Linux
2013-01-03 11:21 ` Russell King - ARM Linux
2013-01-03 11:21 ` Russell King - ARM Linux
2013-01-03 13:45 ` Dan Carpenter
2013-01-03 13:45 ` Dan Carpenter
2013-01-03 13:45 ` Dan Carpenter
2013-01-03 13:52 ` Russell King - ARM Linux
2013-01-03 13:52 ` Russell King - ARM Linux
2013-01-03 13:52 ` Russell King - ARM Linux
2013-01-02 9:26 ` Russell King - ARM Linux
2013-01-02 9:26 ` Russell King - ARM Linux
2013-01-02 9:26 ` Russell King - ARM Linux
2013-01-02 9:44 ` Julia Lawall
2013-01-02 9:44 ` Julia Lawall
2013-01-02 9:44 ` Julia Lawall
2013-01-02 10:15 ` Russell King - ARM Linux
2013-01-02 10:15 ` Russell King - ARM Linux
2013-01-02 10:15 ` Russell King - ARM Linux
2013-01-02 23:14 ` Sylwester Nawrocki
2013-01-02 23:14 ` Sylwester Nawrocki
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
2012-12-18 18:42 ` Dan Carpenter
2012-12-18 18:42 ` 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=1357104713.30504.8.camel@gitbox \
--to=linux@prisktech.co.nz \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.