[lkml]   [2017]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] ARM: owl: smp: Drop owl_secondary_boot()
On 07/06/2017 10:39 AM, Mark Rutland wrote:
> On Thu, Jul 06, 2017 at 07:17:28PM +0200, Andreas Färber wrote:
>> Am 05.07.2017 um 04:36 schrieb Florian Fainelli:
>>> On July 4, 2017 4:32:18 PM PDT, "Andreas Färber" <> wrote:
>>>> Commit 18cfd9429d8a82c49add8f3ca9d366599bfcac45 ("ARM: owl: smp: Drop
>>>> bogus holding pen") simplified the S500 SMP code by removing a loop for
>>>> pen_release in owl_secondary_boot(). Since then it is only calling
>>>> owl_v7_invalidate_l1() before branching to secondary_startup().
>>>> The owl_v7_invalidate_l1() assembler function is superfluous, too.
>>>> Therefore drop owl_secondary_boot() and use secondary_boot() directly.
>>>> Cc: David Liu <>
>>>> Signed-off-by: Andreas Färber <>
>>>> ---
>>>> - writel(virt_to_phys(owl_secondary_startup),
>>>> + writel(virt_to_phys(secondary_startup),
>>>> timer_base_addr + OWL_CPU1_ADDR + (cpu - 1) * 4);
>>> This is a kernel symbol so please use __pa_symbol() here, also you might want to build with CONFIG_DEBUG_VIRTUAL and see if you get other warnings about using virt_to_phys() in the owl platform code (I did not check if there are other uses)
>> Thanks for the report. There are no other such uses in mach-actions, but
>> git-grep'ing for virt_to_phys in arch/arm/mach-* I spot at least one
>> other such usage in mach-oxnas:
>> arch/arm/mach-oxnas/platsmp.c:
>> writel(virt_to_phys(ox820_secondary_startup),
>> as well as this in mach-mvebu:
>> arch/arm/mach-mvebu/platsmp.c: writel(virt_to_phys(boot_addr), base +
>> and these in mach-at91:
>> arch/arm/mach-at91/pm.c: pm_bu->canary = virt_to_phys(&canary);
>> arch/arm/mach-at91/pm.c: pm_bu->resume = virt_to_phys(cpu_resume);
>> What exactly is the difference between the two macros that makes it
>> wrong despite apparently working?
> virt_to_phys() is intended to operate on the linear/direct mapping of
> RAM.
> __pa_symbol() is intended to operate on the kernel mapping, which may
> not be in the linear/direct mapping on all architectures. e.g. arm64 and
> x86_64 map the kernel image and RAM separately.
> On 32-bit ARM the kernel image mapping is tied to the linear/direct
> mapping, so that works, but as it's semantically wrong (and broken for
> generic code), the DEBUG_VIRTUAL checks complain.
>> In particular I am wondering whether
>> the SoC/board vendors in CC need to fix it in their 3.10 trees, too.
>> In any case if this is a bug, I would rather fix it in a separate patch
>> for 4.13 and leave the name swap (this patch) for 4.14.
> To the best of my knowledge there's no functional problem in this
> particular case, though it should be cleaned up so as to keep

Exactly, it just happened to catch my eye while looking at this patch
series. I am wondering if there is a way we could check whether it makes
sense to use virt_to_phys() vs. __pa_symbol() at compile time and
produce an appropriate warning would that be the case.
would not be able to do this unless there is a prior build of the kernel
image, and a GCC plugin would not necessarily have global visibility
about other translation units either... hmmm.

 \ /
  Last update: 2017-07-06 23:17    [W:0.200 / U:0.036 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site