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] [day] [month] [year] [list]
Date:   Thu, 2 Jul 2020 08:14:17 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Nathan Chancellor <natechancellor@...il.com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Gregory CLEMENT <gregory.clement@...tlin.com>,
        linux-clk@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clk: mvebu: ARMADA_AP_CPU_CLK needs to select
 ARMADA_AP_CP_HELPER

On 01-07-20, 13:11, Nathan Chancellor wrote:
> When building arm32 allmodconfig:
> 
> ld.lld: error: undefined symbol: ap_cp_unique_name
> >>> referenced by ap-cpu-clk.c
> >>>               clk/mvebu/ap-cpu-clk.o:(ap_cpu_clock_probe) in archive drivers/built-in.a
> 
> ap_cp_unique_name is only compiled into the kernel image when
> CONFIG_ARMADA_AP_CP_HELPER is selected (as it is not user selectable).
> However, CONFIG_ARMADA_AP_CPU_CLK does not select it.
> 
> This has been a problem since the driver was added to the kernel but it
> was not built before commit c318ea261749 ("cpufreq: ap806: fix cpufreq
> driver needs ap cpu clk") so it was never noticed.
> 
> Fixes: f756e362d938 ("clk: mvebu: add CPU clock driver for Armada 7K/8K")
> Signed-off-by: Nathan Chancellor <natechancellor@...il.com>
> ---
> 
> I do not know who should actually take this patch since the problematic
> patch is on Viresh's cpufreq/arm/linux-next

That patch just enabled the config option and I have picked it up for
5.9.

> but the problem originated
> from a patch in the clk tree in 5.4. I assume all that would be needed
> is a clk maintainer's ack? Please let me know if I did something wrong.

This patch should go through clk tree and get pushed for 5.8 if
possible (which makes sense as well).

-- 
viresh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ