linux-kernel - Re: [PATCH v2 1/2] clk: tegra: Mark HCLK, SCLK, EMC, MC and PLL

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: <151372175856.45969.11728164366457295655@resonance>
Date:   Tue, 19 Dec 2017 14:15:58 -0800
From:   Michael Turquette <mturquette@...libre.com>
To:     Dmitry Osipenko <digetx@...il.com>,
        "Peter De Schrijver" <pdeschrijver@...dia.com>,
        "Prashant Gaikwad" <pgaikwad@...dia.com>,
        "Stephen Boyd" <sboyd@...eaurora.org>,
        "Thierry Reding" <thierry.reding@...il.com>,
        "Jonathan Hunter" <jonathanh@...dia.com>
Cc:     linux-clk@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] clk: tegra: Mark HCLK, SCLK, EMC,
 MC and PLL_P outputs as critical

Quoting Dmitry Osipenko (2017-12-19 12:20:56)
> On 19.12.2017 22:56, Michael Turquette wrote:
> > Quoting Dmitry Osipenko (2017-12-18 19:59:06)
> >> Machine dies if HCLK, SCLK or EMC is disabled, hence mark these clocks
> >> as critical. Currently some of drivers do not manage clocks properly,
> >> expecting clocks to be 'always enabled', these clocks are MC and PLL_P
> >> outputs. Let's mark MC or PLL_P outputs as critical for now and revert
> >> this change once drivers would be corrected.
> > 
> > Are the drivers that do not manage their clocks correctly merged
> > upstream? If so can we fix those drivers instead of marking clocks as
> > critical?
> 
> All the drivers are in upstream for a quite long time already. We should be able
> to correct them, but I haven't tried yet.
> 
> > If not can we annotate the flags below with a comment stating to remove
> > the critical clock flag once the consumer driver gets a clue?
> I'll try to take a look at how much effort it would take to correct the drivers
> during the next few days and will send v3 with either the comment being added or
> 'always enabled' clocks being dropped from the patch.

Great, thanks for looking into it. Critical clocks are an easy-to-abuse
feature and we should really be using the clk.h api as much as possible
in place of the critical clocks mechanism.

Best regards,
Mike