Messages in this thread | | | Subject | Re: [PATCH v2 0/2] Fix missing entropy on Zynq arch due to get_cycles() not supported | From | Michal Simek <> | Date | Tue, 27 Apr 2021 16:19:20 +0200 |
| |
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
| |