Re: [PATCH v2 0/2] Fix missing entropy on Zynq arch due to get_cycles() not supported

[Michal Simek <michal.simek@xilinx.com>]

Hi,

On 4/6/21 3:00 PM, Andrea Merello wrote:
> Changes wrt v1:
>  - rebased on latest kernel tree
>  - fix cover letter: does -> doesn't
> 
> A real-world problem has been seen with a Zynq-based board running
> Debian 10, where ssh daemon takes a really long time to come up at boot.
> This is due to lack of random numbers.
> 
> Since commit 50ee7529ec450 ("random: try to actively add entropy rather
> than passively wait for it") we try to generate entropy whenever we are
> in short of random numbers and someone needs them.
> 
> This trick works only when CPU cycle counter is available. On ARM this
> means that get_cycles() works and in turn read_current_timer() works.
> 
> Zynq HW includes two "cadence TTC" timers and the "ARM global timer".
> All these pieces of HW are fed by the CPU clock, which dynamically
> changes whenever CPU frequency scaling is enabled.
> 
> In timer-cadence-ttc driver this scenario is handled by looking at parent
> clock changes and adjusting things when required. This is the only usable
> clocksource when CPU frequency scaling is in use. arm_global_timer driver
> is disabled in Kconfig when CPU_FREQ is enabled for Zynq arch.
> 
> Unfortunately timer-cadence-ttc driver doesn't register itself via
> register_current_timer_delay() and that ultimately ends up in get_cycles()
> to always return zero, causing the aforementioned lack of entropy problem.
> I believe that the reason for this is because Cadence TTC counter on Zynq
> silicon is only 16-bit wide.
> 
> This patchset works around this by implementing in ARM global timer driver
> a mechanism to compensate for parent clock variations, similarly to what
> it's done in Cadence TTC timer driver, so that it can be used together
> with CPU frequency scaling on Zynq arch.
> 
> This proved to finally fix the problem on my Zynq-based Z-turn board.
> 
> Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
> 
> Andrea Merello (2):
>   clocksource: arm_global_timer: implement rate compensation whenever
>     source clock changes
>   arm: zynq: don't disable CONFIG_ARM_GLOBAL_TIMER due to
>     CONFIG_CPU_FREQ anymore
> 
>  arch/arm/mach-zynq/Kconfig             |   2 +-
>  drivers/clocksource/Kconfig            |  14 +++
>  drivers/clocksource/arm_global_timer.c | 122 +++++++++++++++++++++++--
>  3 files changed, 127 insertions(+), 11 deletions(-)
> 
> --
> 2.17.1
> 

I have no problem with these patches. I have tested it on zc706 board
and I see performance improvement when I generate random numbers.

Only question what I have is if ARM_GT_INITIAL_PRESCALER_VAL=2 make
sense also for others SoC with multi_v7_defconfig.

Other than this feel free to add my
Acked-by: Michal Simek <michal.simek@xilinx.com>
Tested-by: Michal Simek <michal.simek@xilinx.com> (on Zynq)

Daniel: Can you please take a look at this series?

Thanks,
Michal