From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ARM: early_printk: use printascii() rather than printch()
Date: Thu, 2 Nov 2017 00:09:45 +0000 [thread overview]
Message-ID: <20171102000945.GT9463@n2100.armlinux.org.uk> (raw)
In-Reply-To: <SG2PR06MB1165AE45FB289039E55D03028A5E0@SG2PR06MB1165.apcprd06.prod.outlook.com>
On Tue, Oct 31, 2017 at 07:12:32PM +0000, Chris Brandt wrote:
> On Tuesday, October 31, 2017, Nicolas Pitre wrote:
> > On Tue, 31 Oct 2017, Russell King - ARM Linux wrote:
> > > On Tue, Oct 31, 2017 at 02:15:14PM -0400, Nicolas Pitre wrote:
> > > > On Tue, 31 Oct 2017, Russell King - ARM Linux wrote:
> > > > > So a printch('\n') produces "\n\r" on the UART. If we're fixing
> > > > > printascii() to emit "\r\n" instead of "\n\r" for a '\n', then
> > > > > printch() should have the same fix, and should not truncate to
> > > > > just '\n'.
> > > >
> > > > OK... That's easy to achieve, but is it desirable?
> > >
> > > Yes - remember, these are supposed to be usable from assembly,
> > > and we really don't want to have the complexity of:
> > >
> > > mov r0, #'\r'
> > > bl printch
> > > mov r0, #'\n'
> > > bl printch
> > >
> > > each time we want to begin a new line.
> >
> > Fine with me.
> >
> > diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S
> > index ea9646cc2a..01d746efff 100644
> > --- a/arch/arm/kernel/debug.S
> > +++ b/arch/arm/kernel/debug.S
> > @@ -79,25 +79,28 @@ hexbuf: .space 16
> >
> > ENTRY(printascii)
> > addruart_current r3, r1, r2
> > - b 2f
> > -1: waituart r2, r3
> > - senduart r1, r3
> > - busyuart r2, r3
> > - teq r1, #'\n'
> > - moveq r1, #'\r'
> > - beq 1b
> > -2: teq r0, #0
> > +1: teq r0, #0
> > ldrneb r1, [r0], #1
> > teqne r1, #0
> > - bne 1b
> > - ret lr
> > + reteq lr
> > +2: teq r1, #'\n'
> > + bne 3f
> > + mov r1, '\r'
> > + waituart r2, r3
> > + senduart r1, r3
> > + busyuart r2, r3
> > + mov r1, '\n'
> > +3: waituart r2, r3
> > + senduart r1, r3
> > + busyuart r2, r3
> > + b 1b
> > ENDPROC(printascii)
> >
> > ENTRY(printch)
> > addruart_current r3, r1, r2
> > mov r1, r0
> > mov r0, #0
> > - b 1b
> > + b 2b
> > ENDPROC(printch)
> >
> > #ifdef CONFIG_MMU
>
>
> This patch worked for me.
> I get my carriage returns again.
Sorry, but no. This is crap.
The kernelci.org test resulting from the tree I pushed out this evening
with both of the patches in is very unhappy:
42 arch/arm/kernel/debug.S:98: Error: immediate expression requires a # prefix -- `mov r1,10'
42 arch/arm/kernel/debug.S:94: Error: immediate expression requires a # prefix -- `mov r1,13'
I can't believe that anyone actually build-tested this patch as it
stands - maybe, Chris, you just think you did but you ended up
testing something else? Or maybe your binutils is broken because
it now accepts constants without the preceding '#' ?
Shrug, whatever, Nico's patches are broken, and it's way too late to
go through another round of potential broken-ness. Dropping both
from my tree until after the merge window. Sorry.
Last minute fixes hardly ever work out.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
next prev parent reply other threads:[~2017-11-02 0:09 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-02 2:06 [PATCH 0/3] a few debug_ll fixes and improvements Nicolas Pitre
2017-10-02 2:06 ` [PATCH 1/3] ARM: debug.S: move hexbuf to a writable section Nicolas Pitre
2017-10-02 2:06 ` [PATCH 2/3] ARM: semihosting: use proper instruction on v7m processors Nicolas Pitre
2017-10-02 2:06 ` [PATCH 3/3] ARM: early_printk: use printascii() rather than printch() Nicolas Pitre
2017-10-02 5:20 ` Uwe Kleine-König
2017-10-02 14:09 ` Nicolas Pitre
2017-10-31 11:28 ` Chris Brandt
2017-10-31 16:22 ` Nicolas Pitre
2017-10-31 16:38 ` Robin Murphy
2017-10-31 17:06 ` Nicolas Pitre
2017-10-31 17:16 ` Russell King - ARM Linux
2017-10-31 17:48 ` Nicolas Pitre
2017-10-31 17:53 ` Russell King - ARM Linux
2017-10-31 18:15 ` Nicolas Pitre
2017-10-31 18:20 ` Russell King - ARM Linux
2017-10-31 18:35 ` Nicolas Pitre
2017-10-31 19:12 ` Chris Brandt
2017-10-31 19:28 ` Nicolas Pitre
2017-10-31 21:50 ` Russell King - ARM Linux
2017-10-31 23:35 ` Nicolas Pitre
2017-10-31 23:50 ` Russell King - ARM Linux
2017-11-02 0:09 ` Russell King - ARM Linux [this message]
2017-11-02 3:59 ` Nicolas Pitre
2017-11-02 4:16 ` Nicolas Pitre
2017-11-02 11:09 ` Russell King - ARM Linux
2017-11-02 15:12 ` Nicolas Pitre
2017-11-02 11:06 ` Chris Brandt
2017-11-02 11:20 ` Russell King - ARM Linux
2017-11-02 11:28 ` Chris Brandt
2017-11-02 13:04 ` Russell King - ARM Linux
2017-11-02 15:04 ` Nicolas Pitre
2017-11-02 15:18 ` Robin Murphy
2017-11-02 15:22 ` Russell King - ARM Linux
2017-11-02 15:25 ` Chris Brandt
2017-11-02 15:23 ` Chris Brandt
2017-11-02 15:35 ` Nicolas Pitre
2017-11-02 16:06 ` Nicolas Pitre
2017-11-02 16:38 ` Chris Brandt
2017-11-02 17:10 ` Russell King - ARM Linux
2017-11-02 17:20 ` Nicolas Pitre
2017-11-02 17:28 ` Chris Brandt
2017-11-02 18:29 ` Robin Murphy
2017-11-02 21:46 ` syntax unified, was " Nicolas Pitre
2017-11-02 15:48 ` Russell King - ARM Linux
2017-11-02 16:30 ` Chris Brandt
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=20171102000945.GT9463@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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).