| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <ca4e1c30-1faf-f4e5-980b-20f5307a580c@microchip.com>
Date: Thu, 18 May 2023 07:38:54 +0000
From: <Claudiu.Beznea@...rochip.com>
To: <maxime@...no.tech>, <mturquette@...libre.com>, <sboyd@...nel.org>,
<afaerber@...e.de>, <mani@...nel.org>,
<Nicolas.Ferre@...rochip.com>, <alexandre.belloni@...tlin.com>,
<jcmvbkbc@...il.com>, <ckeepax@...nsource.cirrus.com>,
<rf@...nsource.cirrus.com>, <mcoquelin.stm32@...il.com>,
<alexandre.torgue@...s.st.com>, <luca.ceresoli@...tlin.com>,
<david@...hnology.com>, <nsekhar@...com>, <abelvesa@...nel.org>,
<shawnguo@...nel.org>, <s.hauer@...gutronix.de>,
<kernel@...gutronix.de>, <festevam@...il.com>, <linux-imx@....com>,
<matthias.bgg@...il.com>, <geert+renesas@...der.be>,
<dinguyen@...nel.org>, <pdeschrijver@...dia.com>,
<pgaikwad@...dia.com>, <thierry.reding@...il.com>,
<jonathanh@...dia.com>, <ulf.hansson@...aro.org>,
<linus.walleij@...aro.org>, <airlied@...il.com>, <daniel@...ll.ch>,
<vkoul@...nel.org>, <kishon@...nel.org>, <a.zummo@...ertech.it>,
<wens@...e.org>, <jernej.skrabec@...il.com>, <samuel@...lland.org>,
<lgirdwood@...il.com>, <broonie@...nel.org>, <perex@...ex.cz>,
<tiwai@...e.com>, <paul@...pouillou.net>, <orsonzhai@...il.com>,
<baolin.wang@...ux.alibaba.com>, <zhang.lyra@...il.com>
CC: <linux-clk@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<angelogioacchino.delregno@...labora.com>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-actions@...ts.infradead.org>,
<patches@...nsource.cirrus.com>,
<linux-stm32@...md-mailman.stormreply.com>,
<linux-mediatek@...ts.infradead.org>,
<linux-renesas-soc@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
<dri-devel@...ts.freedesktop.org>, <linux-phy@...ts.infradead.org>,
<linux-rtc@...r.kernel.org>, <linux-sunxi@...ts.linux.dev>,
<alsa-devel@...a-project.org>, <linux-mips@...r.kernel.org>
Subject: Re: [PATCH v3 46/65] clk: at91: smd: Switch to determine_rate
On 04.04.2023 13:11, Maxime Ripard wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> The Atmel SAM9x5 SMD clocks implements a mux with a set_parent
> hook, but doesn't provide a determine_rate implementation.
>
> This is a bit odd, since set_parent() is there to, as its name implies,
> change the parent of a clock. However, the most likely candidate to
> trigger that parent change is a call to clk_set_rate(), with
> determine_rate() figuring out which parent is the best suited for a
> given rate.
>
> The other trigger would be a call to clk_set_parent(), but it's far less
> used, and it doesn't look like there's any obvious user for that clock.
>
> So, the set_parent hook is effectively unused, possibly because of an
> oversight. However, it could also be an explicit decision by the
> original author to avoid any reparenting but through an explicit call to
> clk_set_parent().
>
> The driver does implement round_rate() though, which means that we can
> change the rate of the clock, but we will never get to change the
> parent.
>
> However, It's hard to tell whether it's been done on purpose or not.
>
> Since we'll start mandating a determine_rate() implementation, let's
> convert the round_rate() implementation to a determine_rate(), which
> will also make the current behavior explicit. And if it was an
> oversight, the clock behaviour can be adjusted later on.
>
> Signed-off-by: Maxime Ripard <maxime@...no.tech>
Reviewed-by: Claudiu Beznea <claudiu.beznea@...rochip.com>
Tested-by: Claudiu Beznea <claudiu.beznea@...rochip.com>
> ---
> drivers/clk/at91/clk-smd.c | 29 +++++++++++++++++------------
> 1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-smd.c b/drivers/clk/at91/clk-smd.c
> index 160378438f1b..09c649c8598e 100644
> --- a/drivers/clk/at91/clk-smd.c
> +++ b/drivers/clk/at91/clk-smd.c
> @@ -36,26 +36,31 @@ static unsigned long at91sam9x5_clk_smd_recalc_rate(struct clk_hw *hw,
> return parent_rate / (smddiv + 1);
> }
>
> -static long at91sam9x5_clk_smd_round_rate(struct clk_hw *hw, unsigned long rate,
> - unsigned long *parent_rate)
> +static int at91sam9x5_clk_smd_determine_rate(struct clk_hw *hw,
> + struct clk_rate_request *req)
> {
> unsigned long div;
> unsigned long bestrate;
> unsigned long tmp;
>
> - if (rate >= *parent_rate)
> - return *parent_rate;
> + if (req->rate >= req->best_parent_rate) {
> + req->rate = req->best_parent_rate;
> + return 0;
> + }
>
> - div = *parent_rate / rate;
> - if (div > SMD_MAX_DIV)
> - return *parent_rate / (SMD_MAX_DIV + 1);
> + div = req->best_parent_rate / req->rate;
> + if (div > SMD_MAX_DIV) {
> + req->rate = req->best_parent_rate / (SMD_MAX_DIV + 1);
> + return 0;
> + }
>
> - bestrate = *parent_rate / div;
> - tmp = *parent_rate / (div + 1);
> - if (bestrate - rate > rate - tmp)
> + bestrate = req->best_parent_rate / div;
> + tmp = req->best_parent_rate / (div + 1);
> + if (bestrate - req->rate > req->rate - tmp)
> bestrate = tmp;
>
> - return bestrate;
> + req->rate = bestrate;
> + return 0;
> }
>
> static int at91sam9x5_clk_smd_set_parent(struct clk_hw *hw, u8 index)
> @@ -98,7 +103,7 @@ static int at91sam9x5_clk_smd_set_rate(struct clk_hw *hw, unsigned long rate,
>
> static const struct clk_ops at91sam9x5_smd_ops = {
> .recalc_rate = at91sam9x5_clk_smd_recalc_rate,
> - .round_rate = at91sam9x5_clk_smd_round_rate,
> + .determine_rate = at91sam9x5_clk_smd_determine_rate,
> .get_parent = at91sam9x5_clk_smd_get_parent,
> .set_parent = at91sam9x5_clk_smd_set_parent,
> .set_rate = at91sam9x5_clk_smd_set_rate,
>
> --
> 2.39.2
>
Powered by blists - more mailing lists