From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3831F33C1B4; Mon, 11 May 2026 11:00:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778497224; cv=none; b=ifHaJjfklPWLReFlTn5cGwtoTFgQFL7qGIRhZik+bKrJJ1oBmkXjkoM+REyLSogX9fEvw0H4K2b3GFu2dGzPJAYY4d8BlbR0R5XAb1te4sLfq36gDkbB+MyZo4IPmRC/StVgSBGxWXAs2Cd96g/54STKYGZB0ZRohaxbjJBgIKg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778497224; c=relaxed/simple; bh=voSZcpcyiSDS3a/reXV/K0I/01RfqWCIKc4QVo8qHck=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bGnfiohNVPPTwLXRondPd5CChAj+T8sr9zhRf2A1MN2OXZv+pWU5rp40eTyBt4D59ZocTwP+qhC5YxAn+i0dpDUhcnoM9l/e1VrtwHJh3xIIYWh/GZaec4Y5I9x2n0uDKMFaEiG7cWe72BR5i8LABzqbKt9EutpnnjHE7P13+0Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=qWKADNI0; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="qWKADNI0" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6F69216F8; Mon, 11 May 2026 04:00:14 -0700 (PDT) Received: from pluto (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 794653F836; Mon, 11 May 2026 04:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778497219; bh=voSZcpcyiSDS3a/reXV/K0I/01RfqWCIKc4QVo8qHck=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qWKADNI07WVf8A2b1p6AnfwABXZ5IAyYR6C6rzl+s6/fUh/FcO0d9Q76KrGL3JnLO LPtwmwejFNKqIFbStehlE8TRZO1LuTrI3NDglR5MR+GGaS1TwuREJmxHWCxTONCzTN mG8sBhQYqlQ6mp8nmR7mzflzIYx3q3mIUTiNfTds= Date: Mon, 11 May 2026 12:00:08 +0100 From: Cristian Marussi To: Sudeep Holla Cc: Cristian Marussi , Geert Uytterhoeven , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org, linux-clk@vger.kernel.org, linux-renesas-soc@vger.kernel.org, philip.radford@arm.com, james.quinlan@broadcom.com, f.fainelli@gmail.com, vincent.guittot@linaro.org, etienne.carriere@foss.st.com, peng.fan@oss.nxp.com, michal.simek@amd.com, geert+renesas@glider.be, kuninori.morimoto.gx@renesas.com, marek.vasut+renesas@gmail.com Subject: Re: [PATCH v4 00/15] SCMI Clock rates discovery rework Message-ID: References: <20260508153300.2224715-1-cristian.marussi@arm.com> <20260511-origami-ape-of-inspiration-7b55f3@sudeepholla> Precedence: bulk X-Mailing-List: linux-renesas-soc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260511-origami-ape-of-inspiration-7b55f3@sudeepholla> 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 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