linux-kernel - Re: [PATCH v2 2/3] clk: ti: check clock type before doing autoidle ops

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: <154385676593.88331.5239924154783168815@swboyd.mtv.corp.google.com>
Date:   Mon, 03 Dec 2018 09:06:05 -0800
From:   Stephen Boyd <sboyd@...nel.org>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Tero Kristo <t-kristo@...com>,
        Andreas Kemnade <andreas@...nade.info>, bcousson@...libre.com,
        letux-kernel@...nphoenux.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
        mturquette@...libre.com, paul@...an.com
Subject: Re: [PATCH v2 2/3] clk: ti: check clock type before doing autoidle ops

Quoting Tony Lindgren (2018-12-03 07:39:10)
> * Stephen Boyd <sboyd@...nel.org> [181130 23:52]:
> > Quoting Tony Lindgren (2018-11-30 07:37:29)
> > > * Tero Kristo <t-kristo@...com> [181130 09:21]:
> > > > On 30/11/2018 09:57, Stephen Boyd wrote:
> > > ...
> > > 
> > > And that way it would just propagate to the parent clock
> > > domain driver and the clock framework does not need to know
> > > about clockdomains. A clockdomain could be just a genpd
> > > domain.
> > > 
> > > Or do you guys have better ideas?
> > > 
> > 
> > Wouldn't the device link in clk framework patches do this for you if we
> > had the RUNTIME_PM flag passed in. If this is about keeping the clock
> > controller active when a consumer device is using it then I think it may
> > work.
> 
> The consumer device stays active just fine with PM runtime
> calls. So yes, the problem is keeping a clock controller forced
> active for the period of consumer device reset. Other than
> that typically autoidle can be just kept enabled.
> 
> Below is a clarified suggested example usage if we wanted to
> use PM runtime on a clock controller device from a consumer
> device reset driver:
> 
> error = pm_runtime_get_dev()
> ...
> cdev = clk_get_device(clk);
> ...
> error = pm_runtime_get(cdev);
> ...
> /* Do the consumer device reset here */
> ...
> pm_runtime_put(cdev);
> pm_runtime_put(dev);
> 

Does the consumer reset use the reset framework or something else? If
the driver is using the reset framework, I would expect the reset
framework to _also_ have device links and keep the clock controller,
i.e. reset provider, active while the reset is being toggled. And this
assumes the reset controller and clock controller code is all rolled up
together in a single driver that can tell itself to deny idle for
certain clks that are associated with whatever resets they affect.