Received: by 10.223.185.116 with SMTP id b49csp3579577wrg; Mon, 26 Feb 2018 02:26:43 -0800 (PST) X-Google-Smtp-Source: AH8x225awdylknwPporEhhaJ4eeWwxN49OJWjVWLyiq/vjI1kkth8o2QhdcDFc2u+yrrMJSL2PU3 X-Received: by 10.99.120.201 with SMTP id t192mr8055570pgc.39.1519640803604; Mon, 26 Feb 2018 02:26:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519640803; cv=none; d=google.com; s=arc-20160816; b=x8cxj80ESHm1zHWlREbSjkG9yY8v19E4JJq5OfI0+/UrFJ8cK/jDTyqtNxq5Qczr1o ggZgJMWfm5ueCfa2bl9PZnAITecg/IBbFXSkd2oJiMUio0DBs3A69BthClwonixWE2Yf t/gnAYpwMTjYdyXiUUdVGcTHCPoGz0qbZCSMn7nKNAIkuEGtTP02svquKL5TshGxCOKx IJmw8CgrIpNQWaN90SbqsNzkJKfCDcfYTDQFFr1QG3FHRxJLm2Th8cw5YTuu1pw8uhiF aNRbTnN3GEgQpcT0nVJu4VIXL24QA2x3sZkhpVDTtkplo5kLxF+oY9WzBKVYBVXV2WT9 2GNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :arc-authentication-results; bh=Tt65RReAZZ/bWt6aHq7xioc/jicrPGEjsr+A2qoJ8M0=; b=UOYA+hahIBHoXU6KxGirZ+thRbDDrt7FpL6nrceOhZxkDtRdnC3AQ1vTGyF9KfXTtC 0LzCnNJdnu6hmgWOZvVJtReJQPaaBIGSrDG71ev3Iu2KSRpmrxqZwlxL6EiyvQvqfA11 ahkD4gEW0qFALyMmMbq6FZ+/O6GcE0/7L42uoK07kBIAdLscAjqALci3TMjd/QtZCqCO f5l6ZT5Fk5ZcRDbull7Zc1mcsjkneKxItNonifPqXkOYkxT+OK7OnMUnJAbAoP9WCjh9 M6N3iEvBgHBEaYQykpMUjaUKPt8YEEgA0VNd6FHyA+d0L+dlF+PgJnfbwUwG7orHp1aa cZ9w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d2si2959911pge.465.2018.02.26.02.26.29; Mon, 26 Feb 2018 02:26:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752554AbeBZKZf convert rfc822-to-8bit (ORCPT + 99 others); Mon, 26 Feb 2018 05:25:35 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:37809 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752523AbeBZKZd (ORCPT ); Mon, 26 Feb 2018 05:25:33 -0500 Received: by mail-wm0-f65.google.com with SMTP id 139so3003986wmn.2; Mon, 26 Feb 2018 02:25:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=plEmtszauDJ6VX8Gz/NS4HTKs8/jXNKKLQpx++gv2pY=; b=eky2Jjajauu3gjHlmkrjLVd/VvEvCb8lozfLnfHPbFjZlrA1ZtBbL8pPTrnJL3Rect VKMPvbP4p6oT0axAWiYa4iRhk0PwbA0m9O2i1+20NoZYaqQUr+EvW4H1e0ztz0u8N90w 9cE3AlWGg2znfB8PwZh51L9/Y9noO2XxGfNKtUsi7UxS6GyQDNj3Xtl8tqJS8V1vHuFi hEclJl7ygLMMp2lCNSJ/P9NBohHsuiUVF+k7/tnQrvEtXOTQadTwv+A4vM7OZxdAyHSv +EjzP1nTN5NwPf11rF5dwxwGN4O73oRqJ+3GZ0nVAiMKUtulHHLZHdjSLZtpUG170AA5 N2Dg== X-Gm-Message-State: APf1xPByo2IcHNIcL2eK7vScw0z2uBti+LUmZ/qUJdQz10p+qZtNZ9qK RNjZRgZYvVxleyrkzVwdzUXuJ8nP X-Received: by 10.80.144.40 with SMTP id b37mr13930492eda.194.1519640732054; Mon, 26 Feb 2018 02:25:32 -0800 (PST) Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com. [209.85.128.176]) by smtp.gmail.com with ESMTPSA id a23sm7441280edd.28.2018.02.26.02.25.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 02:25:31 -0800 (PST) Received: by mail-wr0-f176.google.com with SMTP id p104so20573285wrc.12; Mon, 26 Feb 2018 02:25:31 -0800 (PST) X-Received: by 10.223.135.17 with SMTP id a17mr8699751wra.126.1519640731073; Mon, 26 Feb 2018 02:25:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.134.148 with HTTP; Mon, 26 Feb 2018 02:25:10 -0800 (PST) In-Reply-To: <20180226101252.ozdsxjvawgkemz2c@flea.lan> References: <20180223133742.26044-1-mylene.josserand@bootlin.com> <20180223133742.26044-11-mylene.josserand@bootlin.com> <20180226101252.ozdsxjvawgkemz2c@flea.lan> From: Chen-Yu Tsai Date: Mon, 26 Feb 2018 18:25:10 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 10/10] ARM: sunxi: smp: Add initialization of CNTVOFF To: Maxime Ripard Cc: =?UTF-8?Q?Myl=C3=A8ne_Josserand?= , Russell King , Rob Herring , Mark Rutland , devicetree , linux-arm-kernel , linux-kernel , LABBE Corentin , Thomas Petazzoni , quentin.schulz@bootlin.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 26, 2018 at 6:12 PM, Maxime Ripard wrote: > On Sat, Feb 24, 2018 at 12:17:13AM +0800, Chen-Yu Tsai wrote: >> On Fri, Feb 23, 2018 at 9:37 PM, Mylène Josserand >> wrote: >> > On Cortex-A7, the CNTVOFF register from arch timer is uninitialized. >> > It should be done by the bootloader but it is currently not the case, >> > even for boot CPU because this SoC is booting in secure mode. >> > It leads to an random offset value meaning that each CPU will have a >> > different time, which isn't working very well. >> > >> > Add assembly code used for boot CPU and secondary CPU cores to make >> > sure that the CNTVOFF register is initialized. >> > >> > Signed-off-by: Mylène Josserand >> > --- >> > arch/arm/mach-sunxi/headsmp.S | 21 +++++++++++++++++++++ >> > arch/arm/mach-sunxi/sunxi.c | 4 ++++ >> > 2 files changed, 25 insertions(+) >> > >> > diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S >> > index d5c97e945e69..605896251927 100644 >> > --- a/arch/arm/mach-sunxi/headsmp.S >> > +++ b/arch/arm/mach-sunxi/headsmp.S >> > @@ -65,9 +65,30 @@ ENTRY(sunxi_mc_smp_cluster_cache_enable) >> > first: .word sunxi_mc_smp_first_comer - . >> > ENDPROC(sunxi_mc_smp_cluster_cache_enable) >> > >> > +ENTRY(sunxi_init_cntvoff) >> > + /* >> > + * CNTVOFF has to be initialized either from non-secure Hypervisor >> > + * mode or secure Monitor mode with SCR.NS==1. If TrustZone is enabled >> > + * then it should be handled by the secure code >> > + */ >> > + cps #MON_MODE >> > + mrc p15, 0, r1, c1, c1, 0 /* Get Secure Config */ >> > + orr r0, r1, #1 >> > + mcr p15, 0, r0, c1, c1, 0 /* Set Non Secure bit */ >> > + instr_sync >> > + mov r0, #0 >> > + mcrr p15, 4, r0, r0, c14 /* CNTVOFF = 0 */ >> > + instr_sync >> > + mcr p15, 0, r1, c1, c1, 0 /* Set Secure bit */ >> > + instr_sync >> > + cps #SVC_MODE >> > + ret lr >> > +ENDPROC(sunxi_init_cntvoff) >> >> There is no need to move all the assembly into a separate file, just >> to add this function. Everything can be inlined as a naked function. >> The "instr_sync" macro can be replaced with "isb", which is what it >> expands to anyway. >> >> I really want to keep everything self-contained without global symbols, >> and in C files if possible. > > What is the rationale for keeping it in C files (beside the global > symbols)? Because the syntax is quite ugly, and it's much easier to > read, review and amend using a separate file. Global symbols and keeping everything in one place I guess. This symbol would be used in a few places, so I suppose having it in a separate assembly file would be OK. >> > #ifdef CONFIG_SMP >> > ENTRY(sunxi_boot) >> > bl sunxi_mc_smp_cluster_cache_enable >> > + bl sunxi_init_cntvoff >> > b secondary_startup >> > ENDPROC(sunxi_boot) >> > >> > diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c >> > index 5e9602ce1573..4bb041492b54 100644 >> > --- a/arch/arm/mach-sunxi/sunxi.c >> > +++ b/arch/arm/mach-sunxi/sunxi.c >> > @@ -37,8 +37,12 @@ static const char * const sun6i_board_dt_compat[] = { >> > }; >> > >> > extern void __init sun6i_reset_init(void); >> > +extern void sunxi_init_cntvoff(void); >> > + >> > static void __init sun6i_timer_init(void) >> > { >> > + sunxi_init_cntvoff(); >> >> You should check the enable-method to see if PSCI is set or not, >> as an indicator whether the kernel is booted secure or non-secure. > > It's an indicator, but it's not really a perfect one. You could very > well have your kernel booted in non-secure, without PSCI. Or even with > PSCI, but without the SMP ops. > > We have a quite big number of these cases already, where, depending on > the configuration, we might not have access to the device we write to, > the number of hacks to just enable that device for non-secure is a > good example of that. I wouldn't consider them hacks though. The hardware gives the option to have control of many devices delegated solely to secure-only, or secure/non-secure. Our present model is to support everything we can in Linux directly, instead of through some firmware interface to a non-existent firmware. ChenYu >> AFAIK trying to set CNTVOFF under non-secure would be very bad. > > Just like any other access we do :/ > > Maxime > > -- > Maxime Ripard, Bootlin (formerly Free Electrons) > Embedded Linux and Kernel engineering > https://bootlin.com