From: Rohit Vaswani <rvaswani@codeaurora.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Daniel Walker <dwalker@codeaurora.org>,
Nicolas Pitre <nico@fluxnic.net>,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Jeremy Kerr <jeremy.kerr@canonical.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Jason Wang <jason77.wang@gmail.com>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH] msm: fix debug-macro.S build failure
Date: Thu, 28 Oct 2010 15:36:20 -0700 [thread overview]
Message-ID: <4CC9FAE4.5030605@codeaurora.org> (raw)
In-Reply-To: <20101028174653.GH3122@n2100.arm.linux.org.uk>
On 10/28/2010 10:46 AM, Russell King - ARM Linux wrote:
> 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.
> But do not leave this function empty otherwise if you
> enable DEBUG_LL, you'll get unpredictable behaviour.
>
With DEBUG_LL enabled and if all the 3 macros (addruart, senduart,
waituart) are empty
nothing references these values - so wouldn't this be okay?
> All that you'll then have is a temporary mapping which is torn-down
> when the kernel initializes the page tables properly.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks,
Rohit Vaswani
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2010-10-28 22:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-27 21:58 [PATCH] msm: fix debug-macro.S build failure Daniel Walker
2010-10-27 22:14 ` Russell King - ARM Linux
2010-10-27 22:25 ` [PATCH -v2] " Daniel Walker
2010-10-28 2:30 ` [PATCH] " Nicolas Pitre
2010-10-28 16:30 ` Daniel Walker
2010-10-28 16:35 ` Russell King - ARM Linux
2010-10-28 16:41 ` Daniel Walker
2010-10-28 17:46 ` Russell King - ARM Linux
2010-10-28 18:00 ` Daniel Walker
2010-10-28 18:24 ` Nicolas Pitre
2010-10-28 18:27 ` Daniel Walker
2010-10-28 18:29 ` Russell King - ARM Linux
2010-10-28 18:46 ` Nicolas Pitre
2010-10-28 18:40 ` Nicolas Pitre
2010-10-28 18:28 ` Russell King - ARM Linux
2010-10-28 18:43 ` Nicolas Pitre
2010-10-28 18:46 ` Russell King - ARM Linux
2010-10-29 3:03 ` Nicolas Pitre
2010-10-29 21:17 ` Daniel Walker
2010-10-29 22:14 ` Russell King - ARM Linux
2010-10-29 22:21 ` Daniel Walker
2010-10-29 22:28 ` Russell King - ARM Linux
2010-10-29 23:06 ` [PATCH -v3] " Daniel Walker
2010-10-29 22:17 ` [PATCH] " Nicolas Pitre
2010-10-29 22:32 ` Daniel Walker
2010-10-29 22:53 ` Nicolas Pitre
2010-10-29 23:07 ` Daniel Walker
2010-11-05 21:31 ` David Brown
2010-10-28 22:36 ` Rohit Vaswani [this message]
2010-10-29 2:26 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CC9FAE4.5030605@codeaurora.org \
--to=rvaswani@codeaurora.org \
--cc=dwalker@codeaurora.org \
--cc=jason77.wang@gmail.com \
--cc=jeremy.kerr@canonical.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=lorenzo.pieralisi@arm.com \
--cc=nico@fluxnic.net \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).