linux-kernel - Re: [PATCH v1 1/3] clk: tegra: Convert CCLKG mux to mux + clock divider on Tegra30

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: <b1265595-f01d-5ab2-aaf9-6c4d674f9f3a@gmail.com>
Date:   Wed, 17 Oct 2018 15:27:24 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Jon Hunter <jonathanh@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Peter De Schrijver <pdeschrijver@...dia.com>,
        Prashant Gaikwad <pgaikwad@...dia.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>
Cc:     linux-clk@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/3] clk: tegra: Convert CCLKG mux to mux + clock
 divider on Tegra30

On 10/17/18 11:53 AM, Jon Hunter wrote:
> 
> On 30/08/2018 20:20, Dmitry Osipenko wrote:
>> Some of the CCLKG parents aren't accessible via device tree because they
>> are created as non-DT clocks. Apparently there is no reason to define
>> these clocks in that manner, hence convert CCLKG mux to mux + clock
>> divider to remove the non-DT parent clocks. Now it is possible to request
>> all of CCLKG parents from device tree, which is necessary for the CPUFreq
>> driver.
> 
> Is it likely that all of these clock parents will be used by the CPUFreq
> driver for these devices? If the clocks you currently need are available
> then my preference would be to stick with what we have for now.

You could use them all if you want, that's what HW allow. The current clock description doesn't fully describe the HW, though it should be enough at least for the CPUFreq driver if we are going to use clk_get_sys() and stick to the "default" parent. Peter?