From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Subject: Re: [PATCH v9 3/5] ARM: tegra: split setting of CPU reset handler Date: Tue, 29 Oct 2013 00:18:59 +0000 Message-ID: <20131029001858.GE4763@kartoffel> References: <1382956118-12495-1-git-send-email-acourbot@nvidia.com> <1382956118-12495-4-git-send-email-acourbot@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <1382956118-12495-4-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Alexandre Courbot Cc: Stephen Warren , Russell King , Tomasz Figa , Olof Johansson , Dave P Martin , Arnd Bergmann , Kevin Hilman , "rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org" , Pawel Moll , Ian Campbell , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org On Mon, Oct 28, 2013 at 10:28:36AM +0000, Alexandre Courbot wrote: > Not all Tegra devices can set the CPU reset handler in the same way. > In particular, devices using a TrustZone secure monitor cannot set the > reset handler directly and need to do it through a firmware operation. > > This patch separates the act of setting the reset handler from its > preparation, so the former can be implemented in a different way. > > Signed-off-by: Alexandre Courbot > Reviewed-by: Tomasz Figa > Reviewed-by: Stephen Warren > --- > arch/arm/mach-tegra/reset.c | 27 +++++++++++++++++---------- > 1 file changed, 17 insertions(+), 10 deletions(-) > > diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c > index fd0bbf8..e282395 100644 > --- a/arch/arm/mach-tegra/reset.c > +++ b/arch/arm/mach-tegra/reset.c > @@ -33,26 +33,18 @@ > > static bool is_enabled; > > -static void __init tegra_cpu_reset_handler_enable(void) > +static void __init tegra_cpu_reset_handler_set(const u32 reset_address) > { > - void __iomem *iram_base = IO_ADDRESS(TEGRA_IRAM_RESET_BASE); > void __iomem *evp_cpu_reset = > IO_ADDRESS(TEGRA_EXCEPTION_VECTORS_BASE + 0x100); > void __iomem *sb_ctrl = IO_ADDRESS(TEGRA_SB_BASE); > u32 reg; > > - BUG_ON(is_enabled); > - BUG_ON(tegra_cpu_reset_handler_size > TEGRA_IRAM_RESET_HANDLER_SIZE); > - > - memcpy(iram_base, (void *)__tegra_cpu_reset_handler_start, > - tegra_cpu_reset_handler_size); > - > /* > * NOTE: This must be the one and only write to the EVP CPU reset > * vector in the entire system. > */ > - writel(TEGRA_IRAM_RESET_BASE + tegra_cpu_reset_handler_offset, > - evp_cpu_reset); > + writel(reset_address, evp_cpu_reset); > wmb(); > reg = readl(evp_cpu_reset); > > @@ -66,6 +58,21 @@ static void __init tegra_cpu_reset_handler_enable(void) > writel(reg, sb_ctrl); > wmb(); > } > +} > + > +static void __init tegra_cpu_reset_handler_enable(void) > +{ > + void __iomem *iram_base = IO_ADDRESS(TEGRA_IRAM_RESET_BASE); > + const u32 reset_address = TEGRA_IRAM_RESET_BASE + > + tegra_cpu_reset_handler_offset; > + > + BUG_ON(is_enabled); > + BUG_ON(tegra_cpu_reset_handler_size > TEGRA_IRAM_RESET_HANDLER_SIZE); > + > + memcpy(iram_base, (void *)__tegra_cpu_reset_handler_start, > + tegra_cpu_reset_handler_size); A memcpy to iomem seems suspect. Should this be memcpy_toio, or is the __iomem annotation misleading? Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html