From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from caramon.arm.linux.org.uk ([78.32.30.218]:56815 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760293Ab0J1RrL (ORCPT ); Thu, 28 Oct 2010 13:47:11 -0400 Date: Thu, 28 Oct 2010 18:46:53 +0100 From: Russell King - ARM Linux Subject: Re: [PATCH] msm: fix debug-macro.S build failure Message-ID: <20101028174653.GH3122@n2100.arm.linux.org.uk> References: <1288216688-718-1-git-send-email-dwalker@codeaurora.org> <20101027221428.GB28391@n2100.arm.linux.org.uk> <1288283413.2683.2.camel@c-dwalke-linux.qualcomm.com> <20101028163518.GG3122@n2100.arm.linux.org.uk> <1288284066.2683.9.camel@c-dwalke-linux.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1288284066.2683.9.camel@c-dwalke-linux.qualcomm.com> Sender: linux-arm-msm-owner@vger.kernel.org List-ID: To: Daniel Walker Cc: Nicolas Pitre , linux-arm-msm@vger.kernel.org, linux-arm-kernel , Jeremy Kerr , Lorenzo Pieralisi , Jason Wang , Tony Lindgren On Thu, Oct 28, 2010 at 09:41:06AM -0700, Daniel Walker wrote: > On Thu, 2010-10-28 at 17:35 +0100, Russell King - ARM Linux wrote: > > On Thu, Oct 28, 2010 at 09:30:13AM -0700, Daniel Walker wrote: > > > On Wed, 2010-10-27 at 22:30 -0400, Nicolas Pitre wrote: > > > > On Wed, 27 Oct 2010, Russell King - ARM Linux wrote: > > > > > > > > > > +#else > > > > > > + .macro addruart, rx, tmp > > > > > > > > > > addruart is now expected to return two values, and 'tmp' ends up being > > > > > misleading. This is a recipe for mistakes unless this is corrected. > > > > > It should be 'rp, rv' instead of 'rx, tmp'. > > > > > > > > Also, it is probably not a good idea to return nothing. Otherwise the > > > > code using those macros will then work on random values that just > > > > happened to be in the corresponding register at the call location. > > > > > > Should we have something in generic arm code that allows this to just be > > > turned off? Ideally we don't want any of this stuff even running. > > > > If you don't want it, don't enable DEBUG_LL. DEBUG_LL is what you > > enable for initial board bring-up and once you're getting kernel > > messages via standard console drivers, you disable it. > > This board doesn't have the ability to support DEBUG_LL .. I don't want > the user to have the option to even select that. There is no such option present - and there never has been. This raises the question about what you did before with .phys_io and .io_pg_offst on these platforms which can't support it at all. Effectively, rp is what you would've returned as .phys_io, and rv is the virtual address corresponding to .io_pg_offst - so just replicate that behaviour. But do not leave this function empty otherwise if you enable DEBUG_LL, you'll get unpredictable behaviour. All that you'll then have is a temporary mapping which is torn-down when the kernel initializes the page tables properly.