Re: [PATCH v4 00/15] SCMI Clock rates discovery rework
Cristian Marussi <[email protected]>
| Newsgroups | org.kernel.vger.arm-scmi,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-clk,org.kernel.vger.linux-kernel,org.kernel.vger.linux-renesas-soc |
|---|---|
| Message-ID | <agG2uPsoDZOfEgWX@pluto> |
On Mon, May 11, 2026 at 09:09:40AM +0100, Sudeep Holla wrote: > On Fri, May 08, 2026 at 07:25:49PM +0200, Geert Uytterhoeven wrote: > > Hi Cristian, > > > > On Fri, 8 May 2026 at 17:33, Cristian Marussi <[email protected]> wrote: > > > it was a known limitation, in the SCMI Clock protocol support, the lack of > > > dynamic allocation around per-clock rates discovery: fixed size statically > > > per-clock rates arrays did not scale and was increasingly a waste of memory > > > (see [1]). > > > > [...] > > > > > v3 -->v4 > > > - Rebased on v7.1-rc2 > > > - Removed unused info.rate_discrete [Geert] > > > - Made dev_dbg() more meaningful by printing tot_rates [Geert] > > > - Fixed build bisectability by renaming properly to iter_response_bound_cleanup() > > > > Thanks for the update! > > > > I believe you still have a possible runtime bisectability issue > > between "[PATCH v4 04/15] firmware: arm_scmi: Simplify clock > > rates exposed interface" and "[PATCH v4 05/15] clk: scmi: Use new > > simplified per-clock rate properties": 04/15 removes the last setter > > of scmi_clock_info.rate_discrete, before 05/15 removes the last getter. > > > > I have fixed this up by adding some initialisation in 04/15 and removing it > in 06/15. Cristian, if possible can you check if the functionality will > remain intact after 05/15 ? LGTM. Thanks, Cristian