lkml.org 
[lkml]   [2019]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: clk: rockchip: Checking a kmemdup() call in rockchip_clk_register_pll()
From
Date
> The other option would be to panic, but the kernel should not
> panic if other options are available - and continuing with a static
> pll frequency is less invasive in the error case.

I would like to point out that this function implementation contains
the following source code already.


/* name the actual pll */
snprintf(pll_name, sizeof(pll_name), "pll_%s", name);

pll = kzalloc(sizeof(*pll), GFP_KERNEL);
if (!pll)
return ERR_PTR(-ENOMEM);





> +++ b/drivers/clk/rockchip/clk-pll.c
> @@ -909,14 +909,16 @@ struct clk *rockchip_clk_register_pll(struct rockchip_clk_provider *ctx,

> - pll->rate_count = len;
> pll->rate_table = kmemdup(rate_table,
> pll->rate_count *
> sizeof(struct rockchip_pll_rate_table),
> GFP_KERNEL);
> - WARN(!pll->rate_table,
> - "%s: could not allocate rate table for %s\n",
> - __func__, name);
> +
> + /*
> + * Set num rates to 0 if kmemdup fails. That way the clock
> + * at least can report its rate and stays usable.
> + */
> + pll->rate_count = pll->rate_table ? len : 0;

Can an other error handling strategy make sense occasionally?


if (!pll->rate_table) {
clk_unregister(mux_clk);
mux_clk = ERR_PTR(-ENOMEM);
goto err_mux;
}



Would you like to adjust such exception handling another bit?

Regards,
Markus

\
 
 \ /
  Last update: 2019-10-14 09:27    [W:0.056 / U:3.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site