From: Heiko Stuebner <heiko@sntech.de>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: Stephen Boyd <sboyd@kernel.org>, Kangjie Lu <kjlu@umn.edu>,
Michael Turquette <mturquette@baylibre.com>,
Stephen McCamant <smccaman@umn.edu>,
kernel-janitors@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
linux-rockchip@lists.infradead.org,
Navid Emamdoost <emamd001@umn.edu>,
Aditya Pakki <pakki001@umn.edu>,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: clk: rockchip: Checking a kmemdup() call in rockchip_clk_register_pll()
Date: Tue, 15 Oct 2019 22:29:03 +0200 [thread overview]
Message-ID: <5173392.uhhkXBHGmO@phil> (raw)
In-Reply-To: <45588ab8-2a6c-3f29-61ff-bccf8d6fb291@web.de>
Am Montag, 14. Oktober 2019, 09:26:41 CEST schrieb Markus Elfring:
> > 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?
Nope.
The big difference is that clocks rely heavily on their names to establish
the clock tree parentship. So the PLL cannot work without the name
but can provide some means of functionality without the rate-table
especially as bootloaders do generally initialize a PLL to some form of
sane frequency.
Heiko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-15 20:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-12 13:55 clk: rockchip: Checking a kmemdup() call in rockchip_clk_register_pll() Markus Elfring
2019-10-12 21:32 ` Heiko Stübner
2019-10-13 8:45 ` Markus Elfring
2019-10-13 21:49 ` Heiko Stuebner
2019-10-14 7:26 ` Markus Elfring
2019-10-15 20:29 ` Heiko Stuebner [this message]
2019-10-16 6:24 ` Markus Elfring
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=5173392.uhhkXBHGmO@phil \
--to=heiko@sntech.de \
--cc=Markus.Elfring@web.de \
--cc=emamd001@umn.edu \
--cc=kernel-janitors@vger.kernel.org \
--cc=kjlu@umn.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mturquette@baylibre.com \
--cc=pakki001@umn.edu \
--cc=sboyd@kernel.org \
--cc=smccaman@umn.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox