linux-kernel - Re: [PATCH 2/2] clk: uniphier: add clock data for cpufreq

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: <CAK7LNAQ6XeSHd7DbvD1jWeMfOqk8+R27Q-fNDWtXxpRd=OFgjA@mail.gmail.com>
Date:   Thu, 24 Nov 2016 09:57:32 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Stephen Boyd <sboyd@...eaurora.org>
Cc:     linux-clk <linux-clk@...r.kernel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/2] clk: uniphier: add clock data for cpufreq

Hi Stephen,


2016-11-24 9:05 GMT+09:00 Stephen Boyd <sboyd@...eaurora.org>:

>> +#if 1
>> +     /*
>> +      * TODO:
>> +      * The return type of .round_rate() is "long", which is 32 bit wide on
>> +      * 32 bit systems.  Clock rate greater than LONG_MAX (~ 2.15 GHz) is
>> +      * treated as an error.  Needs a workaround until the problem is fixed.
>> +      */
>
> Just curious is the problem internal to the clk framework because
> of the clk_ops::round_rate design? Or does the consumer, cpufreq
> in this case, have to deal with rates that are larger than
> unsigned long on a 32 bit system? If it's just a clk_ops problem
> and we need to support rates up to 32 bits wide (~ 4.3 GHz) on
> the system then the driver could be changed to use
> .determine_rate() ops and that would allow us to use all the bits
> of unsigned long to figure out rates.
>
> If the problem is rates even larger than unsigned long on 32 bit
> systems, then at the least I'd like to see some sort of plan to
> fix that in the framework before merging code. Hopefully it can
> be done gradually, but as I start looking at it it seems more and
> more complicated to support this so this will be a long term
> project.
>
> We can discuss the clk API changes needed as well if those are
> required, but that is another issue that requires changes in
> other places outside of clk drivers.
>

I understand your point, but core frame-work changes
need more careful review than clk data changes in low-level drivers.
It is too late to be included in v4.10.

If I drop 32bit SoC things, and send v2 only for 64bit SoCs,
is that acceptable for 4.10-rc1?

Our ARMv8 SoCs are more actively developed, so
getting 64bit clk data in first will be helpful.

I postpone the 32bit SoC data until
I figure out the root cause of the problem
(and possible change for the API if necessary).


-- 
Best Regards
Masahiro Yamada