Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <20220202174213.21259-1-tdas@codeaurora.org>
References: <20220202174213.21259-1-tdas@codeaurora.org>
Subject: Re: [PATCH v2 1/2] clk: qcom: clk-rcg2: Update the calc_rate logic to handle determine rate
From:   Stephen Boyd <sboyd@kernel.org>
Cc:     Rajendra Nayak <rnayak@codeaurora.org>,
        linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
        linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org, Taniya Das <tdas@codeaurora.org>
To:     Michael Turquette <mturquette@baylibre.com>,
        Taniya Das <tdas@codeaurora.org>
Date:   Thu, 17 Feb 2022 15:14:14 -0800
User-Agent: alot/0.10
Message-Id: <20220217231416.038AFC340EB@smtp.kernel.org>
Precedence: bulk

Quoting Taniya Das (2022-02-02 09:42:12)
> In the cases where the RCG parent implements the determine rate ops, the
> calc_rate needs to be updated the calculate the rate.

I don't follow. Do you mean in cases where 'rate' is close to 32-bits
and we're running on a CPU with sizeof(long) =3D=3D u32?

>=20
> Fixes: bcd61c0f535a0 ("clk: qcom: Add support for root clock generators (=
RCGs)")
> Signed-off-by: Taniya Das <tdas@codeaurora.org>
> ---
>  * Split the patch for PLL and RCG.
>  * Update the Fixes tag.
>=20
>  drivers/clk/qcom/clk-rcg2.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>=20
> diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
> index e1b1b426fae4..2e120a6dd19a 100644
> --- a/drivers/clk/qcom/clk-rcg2.c
> +++ b/drivers/clk/qcom/clk-rcg2.c
> @@ -147,19 +147,19 @@ static int clk_rcg2_set_parent(struct clk_hw *hw, u=
8 index)
>  static unsigned long
>  calc_rate(unsigned long rate, u32 m, u32 n, u32 mode, u32 hid_div)
>  {
> +       u64 tmp =3D rate;

Call it u64 calced_rate or u64 calculated?

> +
>         if (hid_div) {
> -               rate *=3D 2;
> -               rate /=3D hid_div + 1;
> +               tmp *=3D 2;
> +               do_div(tmp, hid_div + 1);

Can this use div_u64()?

>         }
>=20
>         if (mode) {
> -               u64 tmp =3D rate;
>                 tmp *=3D m;
>                 do_div(tmp, n);

This can probably use div_u64() as well. Do that first in a different
patch and then put this patch on top please.

> -               rate =3D tmp;
>         }
>=20
> -       return rate;
> +       return tmp;
>  }