[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241009-29749473966747300f3d1d3b-pchelkin@ispras.ru>
Date: Wed, 9 Oct 2024 12:01:51 +0300
From: Fedor Pchelkin <pchelkin@...ras.ru>
To: Andrew Lunn <andrew@...n.ch>
Cc: Stephen Boyd <sboyd@...nel.org>, lvc-project@...uxtesting.org,
Michael Turquette <mturquette@...libre.com>,
linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
Gregory Clement <gregory.clement@...tlin.com>,
linux-arm-kernel@...ts.infradead.org,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Subject: Re: [lvc-project] [PATCH v3] clk: mvebu: Prevent division by zero in
clk_double_div_recalc_rate()
Hi Andrew,
On Tue, 08. Oct 23:58, Andrew Lunn wrote:
> On Mon, Oct 07, 2024 at 03:56:29PM -0700, Stephen Boyd wrote:
> > Quoting Alexandra Diupina (2024-09-24 06:14:44)
> > > >> diff --git a/drivers/clk/mvebu/armada-37xx-periph.c b/drivers/clk/mvebu/armada-37xx-periph.c
> > > >> index 8701a58a5804..b32c6d4d7ee5 100644
> > > >> --- a/drivers/clk/mvebu/armada-37xx-periph.c
> > > >> +++ b/drivers/clk/mvebu/armada-37xx-periph.c
> > > >> @@ -343,7 +343,12 @@ static unsigned long clk_double_div_recalc_rate(struct clk_hw *hw,
> > > >> div = get_div(double_div->reg1, double_div->shift1);
> > > >> div *= get_div(double_div->reg2, double_div->shift2);
> > > >>
> > > >> - return DIV_ROUND_UP_ULL((u64)parent_rate, div);
> > > >> + if (!div) {
> > > >> + pr_err("Can't recalculate the rate of clock %s\n", hw->init->name);
> > > > hw->init is set to NULL after registration (see clk_register() code). If
> > > > div is 0 what does the hardware do?
> > >
> > > Thanks for noticing the error. Yes, hw->init is set to zero,
> > > I will replace that code with clk_hw_get_name(hw).
> > > If the value of div is 0, should I return 0 as stated in the
> > > comment for .recalc_rate (in struct clk_ops) or should I
> > > return parent_rate as in some other similar rate recalculation
> > > functions (in some other drivers)?
> >
> > It depends on what the hardware does. Does the hardware pass on the
> > parent rate if the divider is zero? If so, then return parent_rate. Or
> > does it turn off completely? If so, return zero.
>
> I don't think anybody knows what the hardware does in this
> condition. I also suspect it has never happened, or if it has, nobody
> has complained.
>
> I would say, let is divide by 0, so there is an obvious kernel stack
> trace and hopefully a report of the issue. It can then be investigated
> in a way we can then find out what the hardware actually is doing.
Is it worth adding some kind of WARN assertions? Or actually just leave it
for now as is?
Powered by blists - more mailing lists