From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: Runtime warning due to commit 'ARM: OMAP: Catch callers of revision information prior to it being populated' in -next Date: Tue, 19 Apr 2016 07:13:20 -0700 Message-ID: <20160419141320.GB5995@atomide.com> References: <5715B5EC.2040000@roeck-us.net> <57162261.4070409@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from muru.com ([72.249.23.125]:51434 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752775AbcDSONZ (ORCPT ); Tue, 19 Apr 2016 10:13:25 -0400 Content-Disposition: inline In-Reply-To: <57162261.4070409@ti.com> Sender: linux-next-owner@vger.kernel.org List-ID: To: Nishanth Menon Cc: Guenter Roeck , "linux-next@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-omap , "linux-arm-kernel@lists.infradead.org" * Nishanth Menon [160419 05:21]: > On 04/18/2016 11:37 PM, Guenter Roeck wrote: > > + linux-omap, linux-arm > > > commit 'ARM: OMAP: Catch callers of revision information prior to it > > being populated' results in a runtime warning on various non-OMAP > > architectures. I have seen it with the following qemu tests. > > > > arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9 > > arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1 > > arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702 > > arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706 > > arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed > > arm:midway:multi_v7_defconfig:ecx-2000 > > arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310 > > > > It is also reported by kernelci.org in at least one boot test for imx6q-cm-fx6. > > Thanks for the report... :( Oh crap, sorry about that. I'll revert that commit immediately. > > The warning is as follows. > > > > ------------[ cut here ]------------ > > WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/id.c:49 omap_rev+0x3c/0x50 > > Modules linked in: > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc2-next-20160411 #1 > > Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > [] (show_stack) from [] (dump_stack+0x84/0xa4) > > [] (dump_stack) from [] (__warn+0xd4/0x100) > > [] (__warn) from [] (warn_slowpath_null+0x20/0x28) > > [] (warn_slowpath_null) from [] (omap_rev+0x3c/0x50) > > [] (omap_rev) from [] (__omap4_sar_ram_init+0x8/0x88) > > [] (__omap4_sar_ram_init) from [] (do_one_initcall+0x3c/0x16c) > > [] (do_one_initcall) from [] (kernel_init_freeable+0x70/0x1ec) > > [] (kernel_init_freeable) from [] (kernel_init+0x8/0x110) > > [] (kernel_init) from [] (ret_from_fork+0x14/0x3c) > > ---[ end trace cb88537fdc8fa200 ]--- > > > > Please have a look. > > Tony, > Should we get rid of omap_initcall callers(move them into > board-generic call path or lower the check not to include default of 0? Most of those will disappear when we drop the legacy booting support for omap3. I would not touch those before then to avoid churn with the legacy code. Regards, Tony