From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752370AbdLFWEL (ORCPT ); Wed, 6 Dec 2017 17:04:11 -0500 Received: from muru.com ([72.249.23.125]:53892 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751598AbdLFWEJ (ORCPT ); Wed, 6 Dec 2017 17:04:09 -0500 Date: Wed, 6 Dec 2017 14:04:05 -0800 From: Tony Lindgren To: Arnd Bergmann Cc: Dan Murphy , linux-omap , Linux ARM , Linux Kernel Mailing List Subject: Re: [PATCH] ARM: omap2: hide omap3_save_secure_ram on non-OMAP3 builds Message-ID: <20171206220405.GZ28152@atomide.com> References: <20171206141517.670032-1-arnd@arndb.de> <20171206155714.GY28152@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Arnd Bergmann [171206 21:51]: > On Wed, Dec 6, 2017 at 5:29 PM, Dan Murphy wrote: > > Arnd > > > > On 12/06/2017 09:57 AM, Tony Lindgren wrote: > >> * Arnd Bergmann [171206 14:18]: > >>> In configurations without CONFIG_OMAP3 but with secure RAM support, > >>> we now run into a link failure: > >>> > >>> arch/arm/mach-omap2/omap-secure.o: In function `omap3_save_secure_ram': > >>> omap-secure.c:(.text+0x130): undefined reference to `save_secure_ram_context' > >>> > >>> The omap3_save_secure_ram() function is only called from the OMAP34xx > >>> power management code, so we can simply hide that function in the > >>> appropriate #ifdef. > >>> > >>> Fixes: d09220a887f7 ("ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context") > >>> Signed-off-by: Arnd Bergmann > >> > >> Thanks for fixing it, want to apply directly to ARM SoC fixes > >> where d09220a887f7 is now? If so: > >> > >> Acked-by: Tony Lindgren > > > > Found the same issue in our builds. > > Compile tested the patch against different TI defconfig configurations. > > > > Tested-by: Dan Murphy > > Thanks! > > Unfortunately, I found another build problem with CONFIG_PM=n, > sent an updated patch now, and will apply it to the fixes branch > tomorrow keeping both of your Acked-by/Tested-by tags, unless > I hear any objections or run into a third problem. OK thanks works for me. Tony