[PATCH 1/3] ARM: debug: use kconfig choice for selecting DEBUG_LL UART

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Sun, Aug 21, 2011 at 05:00:46PM -0400, Nicolas Pitre wrote:
> On Sun, 21 Aug 2011, Russell King - ARM Linux wrote:
> 
> > On Sun, Aug 21, 2011 at 04:07:37PM -0400, Nicolas Pitre wrote:
> > > On Sun, 21 Aug 2011, Russell King - ARM Linux wrote:
> > > 
> > > > And further to this, I'll point out that the debugging functions are
> > > > *explicitly* designed to avoid corrupting any more than just r0-r3
> > > > and lr.  That's not just the IO functions but also the hex and string
> > > > printing functions.
> > > > 
> > > > And the head*.S code is explicitly written to expect r0-r3 to be
> > > > corrupted - which basically means that no long-term values are held in
> > > > those registers.
> > > 
> > > Well, not exactly.  I actually have a patch to that effect I made a 
> > > while ago so all the early code could be unaffected by inserted function 
> > > call, but held on to it because nothing yet justified its need.  Here it 
> > > is for reference:
> > 
> > And so this buggers up the ability to insert calls to the debugging code
> > by placing values into r0-r3.  So that patch will get a nak too.
> 
> What?  Please look again at the patch and tell me what is wrong with it.
> Because I can't make sense of your last sentence.

Have you not been reading what I've been saying.

Point 1: the code explicitly _avoids_ using r0-r3 except in small short
code sequences.

Point 2: the debugging macros explicitly use r0-r3 because they know that
these registers aren't going to be used in the assembly code except in
small short code sequences.

So, changing all the assembly to use r0-r3 is going to bugger up the
ability to use the debugging macros.  Therefore this is a change with
a net reduction in facility.  Therefore I don't want it.