From mboxrd@z Thu Jan 1 00:00:00 1970 From: skannan@codeaurora.org (Saravana Kannan) Date: Tue, 20 Mar 2012 19:32:56 -0700 Subject: [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn In-Reply-To: References: <1332214706-675-1-git-send-email-skannan@codeaurora.org> <20120320071957.GH3852@pengutronix.de> <348585ed29fb3ff171267c03658e6c0d.squirrel@www.codeaurora.org> Message-ID: <4F693DD8.7070305@codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 03/20/2012 05:13 PM, Turquette, Mike wrote: > On Tue, Mar 20, 2012 at 12:46 AM, Saravana Kannan > wrote: >> On Tue, March 20, 2012 12:19 am, Sascha Hauer wrote: >>> On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote: >>>> 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 >>>> Cc: Mike Turquette >>>> Cc: Andrew Lunn >>>> Cc: Rob Herring >>>> Cc: Russell King >>>> Cc: Jeremy Kerr >>>> Cc: Thomas Gleixner >>>> Cc: Arnd Bergman >>>> Cc: Paul Walmsley >>>> Cc: Shawn Guo >>>> Cc: Sascha Hauer >>>> Cc: Jamie Iles >>>> Cc: Richard Zhao >>>> Cc: Saravana Kannan >>>> Cc: Magnus Damm >>>> Cc: Mark Brown >>>> Cc: Linus Walleij >>>> Cc: Stephen Boyd >>>> Cc: Amit Kucheria >>>> Cc: Deepak Saxena >>>> Cc: Grant Likely >>>> --- >>>> 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. No problem, go for it. > >> 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... The last discussion I remember, NULL was considered a valid clock. So, I think on error, we shouldn't ever return NULL when the return type is struct clk *. Thanks, Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.