linux-kernel - Re: [PATCH] clk: imx: add CLK_GET_RATE_NOCACHE flag for i.MX8M composite clock

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: <1545129634.5874.20.camel@pengutronix.de>
Date:   Tue, 18 Dec 2018 11:40:34 +0100
From:   Lucas Stach <l.stach@...gutronix.de>
To:     Fabio Estevam <festevam@...il.com>,
        Anson Huang <anson.huang@....com>
Cc:     "sboyd@...nel.org" <sboyd@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        Fabio Estevam <fabio.estevam@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] clk: imx: add CLK_GET_RATE_NOCACHE flag for i.MX8M
 composite clock

Am Dienstag, den 18.12.2018, 08:24 -0200 schrieb Fabio Estevam:
> Hi Anson,
> 
> On Tue, Dec 18, 2018 at 12:56 AM Anson Huang <anson.huang@....com>
> wrote:
> > 
> > On i.MX8M, some of the bus clocks' rate could be changed in TF-A,
> 
> Do you mean ATF (ARM Trusted Firmware) instead?

TF-A is the name of the day for what was formerly known as ATF...

However I don't think that it's correct to just don't cache the clock
settings. Normally the secure world firmware should not change any
clock settings at runtime, or it would run into all kinds of conflicts
with the clock driver. So there are probably some well known points in
time like a suspend or resume event when the firmware might change
clock settings, so we could instead use those to trigger an explicit
invalidate of the clock caches with much lower overhead.

Regards,
Lucas