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:   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

Powered by blists - more mailing lists