lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z68GjM-X7Qkpyv7B@hovoldconsulting.com>
Date: Fri, 14 Feb 2025 10:02:04 +0100
From: Johan Hovold <johan@...nel.org>
To: Taniya Das <quic_tdas@...cinc.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>,
	Ajit Pandey <quic_ajipan@...cinc.com>,
	Imran Shaik <quic_imrashai@...cinc.com>,
	Jagadeesh Kona <quic_jkona@...cinc.com>,
	linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Add support to reconfigure PLL

On Tue, Feb 04, 2025 at 11:13:08PM +0530, Taniya Das wrote:
> On 2/4/2025 3:38 PM, Johan Hovold wrote:
> > On Mon, Jan 13, 2025 at 10:57:03PM +0530, Taniya Das wrote:
> >> During boot-up, there is a possibility that the PLL configuration might
> >> be missed even after invoking pll_configure() from the clock controller
> >> probe. This is often due to the PLL being connected to rail or rails
> >> that are in an OFF state and current clock controller also cannot vote
> >> on multiple rails. As a result, the PLL may be enabled with suboptimal
> >> settings, leading to functional issues.
> >>
> >> The PLL configuration, now part of clk_alpha_pll, can be reused to
> >> reconfigure the PLL to a known good state before scaling for frequency.
> >> The 'clk_alpha_pll_reconfigure()' can be updated to support more PLLs
> >> in future.
> > 
> > This sounds like a hack. You already describe the underlying problem (and
> > indirectly its solution) in the first paragraph above, namely that the
> > video clock controller has not enabled the power domain needed to
> > configure the PLL.
> 
> This is not a hack, but another alternative way to ensure the PLL is 
> configured to the right configuration before being used.

I say it's a hack since it sounds like since you're relying on some
other entity to have enabled resources that this clock controller
depends on.

> > I believe support for clock controllers that need to enable multiple
> > power domains is on its way into 6.15:
> > 
> > 	https://lore.kernel.org/lkml/20250117-b4-linux-next-24-11-18-clock-multiple-power-domains-v10-0-13f2bb656dad@linaro.org/
> > 
> > Perhaps that's what you need to fix this properly.
> 
> Yes, this is just to add a dependency on clock controller to put the 
> rail vote, but this series does not fully solve the clock controller's 
> PLL requirement problems.

Why not? What else is needed beyond enabling the video (?) power domain
before configuring the PLL?

Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ