Thread (106 messages) 106 messages, 18 authors, 2012-04-11

[PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn

From: Turquette, Mike <hidden>
Date: 2012-03-21 00:13:36
Also in: linux-arm-msm, lkml

On Tue, Mar 20, 2012 at 12:46 AM, Saravana Kannan
[off-list ref] wrote:
On Tue, March 20, 2012 12:19 am, Sascha Hauer wrote:
quoted
On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote:
quoted
If memory allocation for the parents array or the parent string fails,
then
fail the registration immediately instead of calling clk_register and
hoping it fails there.

Return -ENOMEM on failure.

Signed-off-by: Saravana Kannan <redacted>
Cc: Mike Turquette <redacted>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Rob Herring <redacted>
Cc: Russell King <redacted>
Cc: Jeremy Kerr <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Arnd Bergman <redacted>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Shawn Guo <redacted>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Jamie Iles <redacted>
Cc: Richard Zhao <redacted>
Cc: Saravana Kannan <redacted>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Mark Brown <redacted>
Cc: Linus Walleij <redacted>
Cc: Stephen Boyd <redacted>
Cc: Amit Kucheria <redacted>
Cc: Deepak Saxena <redacted>
Cc: Grant Likely <redacted>
---
There are still some memory free issues when clk_register() fails, but I
will
fix it when I fixed the other register() fns to return ENOMEM of alloc
failure instead of a NULL.

?drivers/clk/clk-fixed-rate.c | ? 10 +++++++---
?1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index 90c79fb..6423ae9 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device
*dev, const char *name,
? ? ? ? ? ? ?parent_names = kmalloc(sizeof(char *), GFP_KERNEL);

? ? ? ? ? ? ?if (! parent_names)
- ? ? ? ? ? ? ? ? ? ?goto out;
+ ? ? ? ? ? ? ? ? ? ?goto fail_ptr;

? ? ? ? ? ? ?len = sizeof(char) * strlen(parent_name);

? ? ? ? ? ? ?parent_names[0] = kmalloc(len, GFP_KERNEL);

? ? ? ? ? ? ?if (!parent_names[0])
- ? ? ? ? ? ? ? ? ? ?goto out;
+ ? ? ? ? ? ? ? ? ? ?goto fail_str;

? ? ? ? ? ? ?strncpy(parent_names[0], parent_name, len);
? ? ?}
It's easier to add a char *parent to struct clk_fixed and pass it to
clk_register with &fixed->parent. This saves you a kmalloc call and
makes the error path simpler. It's the same way already done in the
divider.
I thought I had done this for v7... hmm looks like one got left out.
I'll line up a patch to get it in sync with the others as part of my
fixes.
I thought about that since I saw the same was done for gated and divider
(I think). Here is my guess at Mike's reasoning for this:

Gated and divider clocks have to have a parent. There's nothing to gate
otherwise. But fixed rate clocks might not have a parent. It could be XO's
or PLLs running off of always on XOs not controlled by the SoC. So, it's
arguable to not have a parent. I don't have a strong opinion on this --
since Mike took the time to write it, it left it to his subjective
preference.
I appreciate the thoughtfulness.  Re-using the same type of mechanism
as the divider and gate clocks will still allow the fixed-rate clock
to be parentless, and it makes for cleaner code, one less allocation
and lines up with how the other single-parent basic clocks are done,
so I'll take that method in instead of your patch.
I sent this patch first since it was around the place I was cleaning up. I
didn't want to actually just shuffle around a bug. As I mentioned, this
patch still leaves a bug open -- what if clk_register() fails. I plan to
fix that once my two patches are picked up (hopefully).
Do you still find it useful to return -ENOMEM from the registration
function instead of a NULL clock?  I'm always worried that people
don't check for error codes on pointers in their platform code and
only check for NULL...

Regards,
Mike
Thanks,
Saravana
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help