> 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

Reply via email to