linux-kernel - Re: Re: [PATCH 09/18] clk: qcom: gcc-sm8250: Set delay for Venus CLK resets

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]

Date: Sat, 27 Jan 2024 17:05:45 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Konrad Dybcio <konrad.dybcio@...aro.org>
Cc: Bryan O'Donoghue <bryan.odonoghue@...aro.org>, 
	Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, 
	Philipp Zabel <p.zabel@...gutronix.de>, Marijn Suijten <marijn.suijten@...ainline.org>, 
	linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Dikshita Agarwal <quic_dikshita@...cinc.com>, Vikash Garodia <quic_vgarodia@...cinc.com>, 
	Manivannan Sadhasivam <mani@...nel.org>
Subject: Re: Re: [PATCH 09/18] clk: qcom: gcc-sm8250: Set delay for Venus CLK
 resets

On Tue, Jan 09, 2024 at 10:33:39AM +0100, Konrad Dybcio wrote:
> 
> 
> On 1/9/24 01:34, Bryan O'Donoghue wrote:
> > On 08/01/2024 12:32, Konrad Dybcio wrote:
> > > Some Venus resets may require more time when toggling. Describe that.
> > 
> > May or does ?
> > 
> > I'd prefer a strong declaration of where this value came from and why its being added.
> > 
> > May is ambiguous.
> > 
> > "Downstream has a 150 us delay for this. My own testing shows this to be necessary in upstream"
> 
> Alright
> 
> > 
> > Later commits want to add a 1000 us delay. Have all of these delays been tested ?
> 
> No, we don't support Venus on many of the newer SoCs..
> 
> 
> > 
> > If not please describe where the values come.
> 
> They come from the downstream Venus driver as you mentioned.
> I checked a couple different downstream SoC kernel trees and
> tried to assign the values based on what I found in a kernel
> for that platform. Some are fairly educated guesses.
> 

It would be nice to have documented for which cases you guessed (and in
which downstream kernel you found other values?), so that if anyone is
coming to the tree later with conflicting information they have a better
chance to reason about the discrepancy.

Thanks,
Bjorn