[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZeHgI2nsADrkecC8@hovoldconsulting.com>
Date: Fri, 1 Mar 2024 15:03:15 +0100
From: Johan Hovold <johan@...nel.org>
To: Gabor Juhos <j4g8y7@...il.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Sricharan Ramabadhran <quic_srichara@...cinc.com>,
Varadarajan Narayanan <quic_varada@...cinc.com>,
Gokul Sriram Palanisamy <quic_gokulsri@...cinc.com>,
Devi Priya <quic_devipriy@...cinc.com>,
Anusha Rao <quic_anusha@...cinc.com>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
Georgi Djakov <gdjakov@...sol.com>, linux-arm-msm@...r.kernel.org,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/7] clk: qcom: gcc-ipq5018: fix terminating of frequency
table arrays
On Fri, Mar 01, 2024 at 02:37:01PM +0100, Gabor Juhos wrote:
> Hi Johan,
>
> 2024. 03. 01. 10:40 keltezéssel, Johan Hovold írta:
> > On Thu, Feb 29, 2024 at 07:07:46PM +0100, Gabor Juhos wrote:
> >> The frequency table arrays are supposed to be terminated with an
> >> empty element. Add such entry to the end of the arrays where it
> >> is missing in order to avoid possible out-of-bound access when
> >> the table is traversed by functions like qcom_find_freq() or
> >> qcom_find_freq_floor().
> >>
> >> Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018")
> >
> > Good find!
> >
> > Looks like these should be backported to the stable kernels as well so
> > someone should add:
> >
> > Cc: stable@...r.kernel.org
> >
> > to all patches except possibly the sc8280xp one (that camera clock
> > controller was added in 6.8-rc1 so that patch does not need it in case
> > you can these fixes in before 6.8 is released).
>
> You are right maybe, although I did not find strong enough reasons for adding
> the stable tags.
>
> Only the changes of the gcc-ipq5018 driver has been tested on real hardware the
> others are not. So those does not fit into the "It must be obviously correct and
> tested." rule.
Since this looks like a straight-forward and obviously correct fix for a
bug which could have bad consequences, not being able to test each patch
on actual hardware is not a problem.
Johan
Powered by blists - more mailing lists