Re: [PATCH] ARM: owl: smp: Drop owl_secondary_boot()
From: Florian Fainelli
Date: Thu Jul 06 2017 - 15:48:22 EST
On 07/06/2017 10:38 AM, Alexandre Belloni wrote:
> On 06/07/2017 at 19:17:28 +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" <afaerber@xxxxxxx> 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 <liuwei@xxxxxxxxxxxxxxxx>
>>>> Signed-off-by: Andreas FÃrber <afaerber@xxxxxxx>
>>>> ---
>>>
>>>> - 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 +
>> MV98DX3236_CPU_RESUME_ADDR_REG);
>>
>> 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);
>>
>
> They can probably use __pa_symbol() (I must admit I didn't know about
> it before this email)
This is fine, do you mind sending fixes for the at91 parts? Gregory, can
you also fix the mv98dx3236 platform SMP code?
Thanks!
--
Florian