linux-kernel - Re: [PATCH 4/5] clk: sunxi-ng: Add driver for A83T CCU

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: <20170303235639.GW25384@codeaurora.org>
Date:   Fri, 3 Mar 2017 15:56:39 -0800
From:   Stephen Boyd <sboyd@...eaurora.org>
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     Chen-Yu Tsai <wens@...e.org>,
        Michael Turquette <mturquette@...libre.com>,
        linux-clk <linux-clk@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/5] clk: sunxi-ng: Add driver for A83T CCU

On 03/03, Maxime Ripard wrote:
> On Wed, Mar 01, 2017 at 11:17:05AM -0800, Stephen Boyd wrote:
> 
> > Can someone explain what the issue is? Could something like
> > clk_get_phase() + clk_get_rate() tell us if we're in one mode
> > vs. the other?
> 
> So we have two modes of operation for that clock, old vs new (I know,
> I didn't pick the names).
> 
> The old mode is what we support right now. It has a combination of a
> linear multiplier and divider, plus some phase controls.
> 
> The new mode however disables the phase controls and adds post-divider
> of 2 on the rate.
> 
> We cannot really rely on the rate itself, since there's a huge overlap
> between the rates we can obtain in the old and new modes. Same thing
> for the phase, having a 0 deg phase is achieved both in the old and
> new modes.
> 
> To make things worse, the new mode is only available on one out of
> three MMC controllers (and associated clocks), and that MMC controller
> needs to set a bit as well to switch to the new mode if needed. So we
> definitely needs some synchronisation there, and also to be able to
> retrieve if the mode switching is available, and if we're already
> using that mode.
> 
> Mike agreed that the easiest way forward was to use a custom function.
> 

Ok. Is there any need to change the mode dynamically at runtime?
Or could it be decided once at clk driver probe time/boot time
and detected via set_phase() failing when we're in the new mode?
At least, it sounds like set_phase() should bail out there
because it doesn't exist, although it could be argued that
setting the phase to something it already is set to is valid and
shouldn't return an error.

I'm not saying I'm opposed to the custom function, just thinking
of alternatives if MMC maintainers don't agree with the custom
function.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project