From: Arnd Bergmann <arnd@arndb.de>
To: Lada Trimasova <Lada.Trimasova@synopsys.com>
Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"noamc@ezchip.com" <noamc@ezchip.com>,
Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: Re: [PATCH] arc: use little endian accesses
Date: Thu, 10 Mar 2016 20:23:59 +0100 [thread overview]
Message-ID: <201603102023.59425.arnd@arndb.de> (raw)
In-Reply-To: <1457636268.457.34.camel@synopsys.com>
On Thursday 10 March 2016, Lada Trimasova wrote:
> Driver is 8250, kernel is built for BE arc, nsim option in model "nsim_isa_big_endian = 1".
>
> With current "readl" and "writel" implementation for ARC we read word from memory without any endianess manipulation. So in case of little endian architecture we get what we want: the first memory byte is the low byte in the word. But in case of big endian architecture the word endianess is swapped: the first memory byte is the high word byte.
>
> And for example, let's see what happens when we use "readl" in function "serial8250_early_in" in driver/tty/serial/8250.
>
> Take a look to one line from memory dump:
> 0xf0000010: 0x0b 0x00 0x00 0x00 0x60 0x00 0x00 0x00
>
> When kernel is built for little endian architecture, we read this data in status register in function "serial_putc" using "readl" function in driver/tty/serial/8250 as:
> r0: 0x0000006
> The low byte is 0x0b, so the condition "if ((status & BOTH_EMPTY) == BOTH_EMPTY)" is true, as BOTH_EMPTY is some mask with low bytes set.
>
> When kernel is built with "CPU_BIG_ENDIAN" and model nsim option is "nsim_isa_big_endian=1", we read this data as:
> r0: 0x6000000
> So as you can see the low byte is 0x00 and above mentioned condition never becomes true, we can't continue initialization.
>
Ok, this sounds like a completely normal architecture implementation then,
and your patch looks correct.
If some other driver breaks because of this change, you should investigate
what went wrong there, and treat it as a driver specific problem.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH] arc: use little endian accesses
Date: Thu, 10 Mar 2016 20:23:59 +0100 [thread overview]
Message-ID: <201603102023.59425.arnd@arndb.de> (raw)
In-Reply-To: <1457636268.457.34.camel@synopsys.com>
On Thursday 10 March 2016, Lada Trimasova wrote:
> Driver is 8250, kernel is built for BE arc, nsim option in model "nsim_isa_big_endian = 1".
>
> With current "readl" and "writel" implementation for ARC we read word from memory without any endianess manipulation. So in case of little endian architecture we get what we want: the first memory byte is the low byte in the word. But in case of big endian architecture the word endianess is swapped: the first memory byte is the high word byte.
>
> And for example, let's see what happens when we use "readl" in function "serial8250_early_in" in driver/tty/serial/8250.
>
> Take a look to one line from memory dump:
> 0xf0000010: 0x0b 0x00 0x00 0x00 0x60 0x00 0x00 0x00
>
> When kernel is built for little endian architecture, we read this data in status register in function "serial_putc" using "readl" function in driver/tty/serial/8250 as:
> r0: 0x0000006
> The low byte is 0x0b, so the condition "if ((status & BOTH_EMPTY) == BOTH_EMPTY)" is true, as BOTH_EMPTY is some mask with low bytes set.
>
> When kernel is built with "CPU_BIG_ENDIAN" and model nsim option is "nsim_isa_big_endian=1", we read this data as:
> r0: 0x6000000
> So as you can see the low byte is 0x00 and above mentioned condition never becomes true, we can't continue initialization.
>
Ok, this sounds like a completely normal architecture implementation then,
and your patch looks correct.
If some other driver breaks because of this change, you should investigate
what went wrong there, and treat it as a driver specific problem.
Arnd
next prev parent reply other threads:[~2016-03-10 19:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-09 17:21 [PATCH] arc: use little endian accesses Lada Trimasova
2016-03-09 17:21 ` Lada Trimasova
2016-03-10 5:05 ` Vineet Gupta
2016-03-10 5:05 ` Vineet Gupta
2016-03-10 5:19 ` Vineet Gupta
2016-03-10 5:19 ` Vineet Gupta
2016-03-10 7:44 ` Alexey Brodkin
2016-03-10 7:44 ` Alexey Brodkin
2016-03-10 9:55 ` Vineet Gupta
2016-03-10 9:55 ` Vineet Gupta
2016-03-10 18:57 ` Lada Trimasova
2016-03-10 18:57 ` Lada Trimasova
2016-03-10 19:23 ` Arnd Bergmann [this message]
2016-03-10 19:23 ` Arnd Bergmann
2016-03-11 12:44 ` Vineet Gupta
2016-03-11 12:44 ` Vineet Gupta
2016-03-12 4:20 ` Vineet Gupta
2016-03-12 4:20 ` Vineet Gupta
2016-03-12 4:20 ` Vineet Gupta
2016-03-12 4:20 ` Vineet Gupta
2016-03-11 5:07 ` Noam Camus
2016-03-11 5:07 ` Noam Camus
2016-03-11 5:07 ` Noam Camus
2016-03-10 7:45 ` Arnd Bergmann
2016-03-10 7:45 ` Arnd Bergmann
2016-03-10 7:45 ` Arnd Bergmann
2016-03-11 5:18 ` Vineet Gupta
2016-03-11 5:18 ` Vineet Gupta
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=201603102023.59425.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=Alexey.Brodkin@synopsys.com \
--cc=Lada.Trimasova@synopsys.com \
--cc=Vineet.Gupta1@synopsys.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=noamc@ezchip.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.