lkml.org 
[lkml]   [2021]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 0/2] Fix missing entropy on Zynq arch due to get_cycles() not supported
From
Date
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

\
 
 \ /
  Last update: 2021-04-27 16:21    [W:0.097 / U:2.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site