From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F39B233924; Sat, 3 Oct 2026 14:22:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791037343; cv=none; b=obGDEtw5bdHszD723+UZY3c/m/BDM1kLDWvMi/Q8FneDUyLFNuhCnCXJr8+ulkabCWT6X9Y8Cm0TmbZQ8nbLYx014guIzW9NJJITkK7BMjE4Za2Vo4ZmkhK0suhznWB97HcW1Qe2422DkN/NSCUvOPrVUaBHQ22PoR4MSl25KBM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791037343; c=relaxed/simple; bh=OZqH9xFumm5503yehfbEr+/pg6CXnmXcbwKTmOKAL/E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EnfRUYXJ3rKavFaZYBAWhA3HvkGbUb3JekE3gzEN3iGzZRVG+k3Nf5T45+QXHVVlQu6Gml8TtvpiekSlO8vBTi05rhg82SIf1Z+jzDaG00xBfrAfIw7f2szL0sFzyYPJ4r9afVRNTM0CFdaHNq+vUATOdyCn0iYE4xaMDWl1SDU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HupJsVVB; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HupJsVVB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 444FD1F0089B; Sat, 3 Oct 2026 14:22:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791037342; bh=wU5rDB+VrDABQDIH5NSBgXFhWETxK1QagBiSzme5jbg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=HupJsVVBF1dHKykTQ4kDj6W1v0bhCqz3zdZNM5z8Ua2I8J6c937ttT5WgloXKLeE8 vxqbwr6qEMHwnyXZ9IVNbXssGaaTYPFsjcVYcOOqEnOoAzOqNLYN0gl1rRtc2e51IK S5XS0v6dBZWkMEru1s6uq63ih7+LVa840i2CC2Fhhnq6GhoXw/YY4jVaC9YY86Giz5 iFADACWg+h+gBa/4m9pvN04TpYbQWis4MhKNIv1hgvP+f17JDQDLIxtRjSnyA6jY8u oKkGSZUp6GjuXpcahihgrxXGzVsYSV4PsQvWfDV9Iqk1YvncaLW5D6Is8IWrY2wytJ rkQdqjWQ524dQ== Date: Sat, 3 Oct 2026 16:22:18 +0200 From: Vinod Koul To: Michal Wilczynski Cc: Neil Armstrong , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Andrzej Hajda , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Lee Jones , Andy Yan , Philipp Zabel , Emil Renner Berthing , Hal Feng , Michael Turquette , Stephen Boyd , Heiko Stuebner , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Dominique Belhachemi , Brian Masney , Jerome Brunet , linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, mfd@lists.linux.dev, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-riscv@lists.infradead.org, Marek Szyprowski , Maud Spierings , Graham Markall , Icenowy Zheng , Chaoyi Chen , Joshua Peisach , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Subject: Re: [PATCH v4 16/20] phy: Add common Innosilicon HDMI PHY helpers Message-ID: References: <20260915-jh7110-clean-send-v4-0-f0e4fd6f2cc8@samsung.com> <20260915-jh7110-clean-send-v4-16-f0e4fd6f2cc8@samsung.com> Precedence: bulk X-Mailing-List: linux-kernel@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: <20260915-jh7110-clean-send-v4-16-f0e4fd6f2cc8@samsung.com> On 15-09-26, 17:32, Michal Wilczynski wrote: > The Innosilicon HDMI PHY IP is used by several SoCs. They differ in > where the PHY register block sits in the register space and in which > pixel clocks they support, but the pre-PLL programming sequence and the > layout of its registers are the same. > > Add a small library holding that shared part: the pre-PLL configuration > table format, a lookup, clk_ops determine_rate and recalc_rate helpers, > and the pre-PLL register programming. Callers pass a regmap, a register > offset for the PHY block, and their own pixel clock table. > > No driver uses it yet; the users are converted separately. Is there anything in phy patches here that has dependency with rest? If not consider splitting it up... > +static u8 inno_read(const struct inno_hdmi_phy_pre_pll *pll, unsigned int reg) > +{ > + unsigned int val; > + int ret; > + > + ret = regmap_read(pll->regmap, inno_reg(pll, reg), &val); > + if (ret) > + return 0; > + > + return val; why not just return regmap_read() There is no logic here, nothing. This is really not ideal. Also why add a wrapper and not use regmap directly? > +/** > + * inno_hdmi_phy_pre_pll_determine_rate - clk_ops.determine_rate helper > + * @pll: pre-PLL instance > + * @req: rate request, updated with the rate the PHY would produce > + * > + * The PHY can only generate the pixel clocks described by its table, so a > + * request that does not appear there is rejected rather than rounded. > + * > + * Return: 0 on success, -EINVAL if the rate is not supported. > + */ > +int inno_hdmi_phy_pre_pll_determine_rate(const struct inno_hdmi_phy_pre_pll *pll, > + struct clk_rate_request *req) > +{ > + const struct inno_hdmi_phy_pre_pll_config *cfg; > + unsigned long rate = rounddown(req->rate, 1000); > + > + for (cfg = pll->table; cfg->pixclock != 0; cfg++) { Is there a chance of null/garbage if we reach end of table? You dont know the size of table, and incrementing pointer without bounds does not look good to me. -- ~Vinod