From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from muru.com ([72.249.23.125]:33640 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751432AbcBKPsQ (ORCPT ); Thu, 11 Feb 2016 10:48:16 -0500 Date: Thu, 11 Feb 2016 07:48:10 -0800 From: Tony Lindgren To: Russell King - ARM Linux Cc: "Woodruff, Richard" , Sasha Levin , "stable@vger.kernel.org" , "stable-commits@vger.kernel.org" , Kees Cook , Laura Abbott , "Menon, Nishanth" , "Kristo, Tero" Subject: Re: [added to the 4.1 stable tree] ARM: OMAP2+: Fix l2_inv_api_params for rodata Message-ID: <20160211154810.GE3500@atomide.com> References: <1455117136-28870-1-git-send-email-sasha.levin@oracle.com> <1455117136-28870-180-git-send-email-sasha.levin@oracle.com> <20160211104147.GT10826@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160211104147.GT10826@n2100.arm.linux.org.uk> Sender: stable-owner@vger.kernel.org List-ID: Hi, * Russell King - ARM Linux [160211 02:43]: > On Thu, Feb 11, 2016 at 04:55:37AM +0000, Woodruff, Richard wrote: > > > From: Sasha Levin [mailto:sasha.levin@oracle.com] > > > Sent: Wednesday, February 10, 2016 9:11 AM > > > > Did you test these changes? I certainly did with off idle and retention idle for omap3 on 3430 and 36xx. And on n900 that's the HS omap 3430. And we don't have any HS 36xx in the mainline. > > > We don't want to write to .text, so let's move l2_inv_api_params > > > to .data and access it via a pointer. > > > > At one point in time some of these functions were copied from DRAM load > > address into SRAM and executed from there. > > > > Some of these sections had to be executed outside of DDR due to issues. > > The copy assumed contagious section. If you move some of the data into > > a separate section and any copy is still in code the result won't work > > as expected. If the code has changed then maybe its OK. Back when > > this code was entered it was hand stepped to ensure correct behavior. > > Yes, this isn't going to work if it is copied out of the DDR, because > moving the data to the .data section and introducing a PC relative > access to it will make the code expect to access data at a relative > offset from the SRAM. > > Sascha, please drop this for now. Hmm did I miss something? Since commit 46e130d298a3 ("ARM: pm: omap3: run the ASM sleep code from DDR") we only run minimal parts of the code in SRAM. Naturally if any SRAM code uses PC relative access things won't work. Here are the only pieces running in SRAM: - omap3_do_wfi running in SRAM only for retention idle as off idle restores DDR for us - For HS omaps, save_secure_ram_context is already in .data as it's only run in SRAM - For some revisions, we have es3_sdrc_fix dynamically copied to SRAM If there are other places that I've missed, please let me know and I'll take a look ASAP! Regards, Tony