linux-kernel - Re: [PATCH v2 01/11] clk: tegra: Switch to using critical clks

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160627083531.GA12863@tbergstrom-lnx.Nvidia.com>
Date:	Mon, 27 Jun 2016 11:35:31 +0300
From:	Peter De Schrijver <pdeschrijver@...dia.com>
To:	Thierry Reding <thierry.reding@...il.com>
CC:	Rhyland Klein <rklein@...dia.com>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	"Alexandre Courbot" <gnurou@...il.com>,
	<linux-clk@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>,
	Stephen Warren <swarren@...dotorg.org>
Subject: Re: [PATCH v2 01/11] clk: tegra: Switch to using critical clks

On Wed, Jun 22, 2016 at 02:16:30PM +0200, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Fri, May 27, 2016 at 04:38:04PM -0400, Rhyland Klein wrote:
> > Mark some of the required-to-be-enabled clks as critical clks. These
> > need to be kept on through the disabling of unused clks during init.
> > They may not get any reference before or after init, but are required
> > to be on, therefore let the core enable them.
> > 
> > Signed-off-by: Rhyland Klein <rklein@...dia.com>
> > ---
> > v2:
> >  - Remove mention of HAND_OFF clks as they are not supported yet.
> > 
> >  drivers/clk/tegra/clk-tegra-periph.c     | 21 ++++++++++++++-------
> >  drivers/clk/tegra/clk-tegra-super-gen4.c | 12 +++++++-----
> >  2 files changed, 21 insertions(+), 12 deletions(-)
> 
> I have some difficulty to follow why some of these clocks are critical.
> It might help if the commit message mentioned why each of these need to
> remain enabled forever, even if never used.
> 
> Also, it's fairly unlikely that pll_p for example would ever get
> disabled because a bunch of others are derived from it. I'm also not
> quite convinced yet that it really is critical. What does it drive which
> isn't claimed by any drivers?
> 

mselect and sclk are clocked from pll_p, however we don't have drivers for
those. Most other peripherals clocked from pll_p can be clockgated by their
driver which can lead to pll_p being turned off causing the system to hang.

Cheers,

Peter.