linux-kernel - Re: [PATCH 2/7] clk: Add basic infrastructure for Pistachio clocks

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: <CAL1qeaGTtMWDM+p+FpDRP=L-yqQ_ai7LY8GwcBUO_C1F+V1LzQ@mail.gmail.com>
Date:	Mon, 30 Mar 2015 17:15:43 -0700
From:	Andrew Bresticker <abrestic@...omium.org>
To:	Stephen Boyd <sboyd@...eaurora.org>
Cc:	Mike Turquette <mturquette@...aro.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Linux-MIPS <linux-mips@...ux-mips.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ezequiel Garcia <ezequiel.garcia@...tec.com>,
	James Hartley <james.hartley@...tec.com>,
	James Hogan <james.hogan@...tec.com>
Subject: Re: [PATCH 2/7] clk: Add basic infrastructure for Pistachio clocks

On Mon, Mar 30, 2015 at 4:59 PM, Stephen Boyd <sboyd@...eaurora.org> wrote:
> On 02/24/15 19:56, Andrew Bresticker wrote:
>> +
>> +void pistachio_clk_force_enable(struct pistachio_clk_provider *p,
>> +                             unsigned int *clk_ids, unsigned int num)
>> +{
>> +     unsigned int i;
>> +     int err;
>> +
>> +     for (i = 0; i < num; i++) {
>> +             struct clk *clk = p->clk_data.clks[clk_ids[i]];
>> +
>> +             if (IS_ERR(clk))
>> +                     continue;
>> +
>> +             err = clk_prepare_enable(clk);
>> +             if (err)
>> +                     pr_err("Failed to enable clock %s: %d\n",
>> +                            __clk_get_name(clk), err);
>> +     }
>> +}
>>
>
> Is this to workaround some problems in the framework where clocks are
> turned off? Or is it that these clocks are already on before we boot
> Linux and we need to make sure the framework knows that?

It's the former.  These clocks are enabled at POR and may only be
gated as the final step to entering suspend, so they must remain on at
runtime.  The issue we were running into was that consumers of these
critical clocks or their descendants would enable/disable their clocks
during boot or runtime PM and cause these clocks to get disabled.
Bumping up the prepare/enable count of these critical clocks seemed
like the best way to handle this - is there a more preferred way?
FWIW, this is also how the Tegra and Rockchip drivers handled this
problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/