From: Arnd Bergmann <arnd@arndb.de>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
Lada Trimasova <Lada.Trimasova@synopsys.com>,
Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Noam Camus <noamc@ezchip.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 08:45:30 +0100 [thread overview]
Message-ID: <201603100845.30602.arnd@arndb.de> (raw)
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA23075F4E8EDF9@us01wembx1.internal.synopsys.com>
On Thursday 10 March 2016, Vineet Gupta wrote:
> On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote:
> > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu
> > and le32_to_cpu because it is not really guaranteed that drivers handles
> > any ordering themselves.
>
> That is the driver issue. readxx as API simply returns data in native endianness.
> We've had EZChip running big endian and so far and they didn't need this change.
Most drivers using readl() or readl_relaxed() expect those to perform byte
swaps on big-endian architectures, as the registers tend to be fixed endian,
so the change seems reasonable.
It depends a little bit on how endian mode is implemented in the CPU: do you
follow the normal model of swapping byte order in the load/store instructions
of the CPU when running big-endian, or is the CPU always running little-endian
but the bus addresses get mangled on byte accesses to give the illusion
of a big-endian system?
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: Lada Trimasova <Lada.Trimasova@synopsys.com>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
Noam Camus <noamc@ezchip.com>
Subject: Re: [PATCH] arc: use little endian accesses
Date: Thu, 10 Mar 2016 08:45:30 +0100 [thread overview]
Message-ID: <201603100845.30602.arnd@arndb.de> (raw)
Message-ID: <20160310074530.k0q3Vq-jwJ3fz76rgpjyg0IyYEPcoqw0ufsSRYDeMQQ@z> (raw)
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA23075F4E8EDF9@us01wembx1.internal.synopsys.com>
On Thursday 10 March 2016, Vineet Gupta wrote:
> On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote:
> > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu
> > and le32_to_cpu because it is not really guaranteed that drivers handles
> > any ordering themselves.
>
> That is the driver issue. readxx as API simply returns data in native endianness.
> We've had EZChip running big endian and so far and they didn't need this change.
Most drivers using readl() or readl_relaxed() expect those to perform byte
swaps on big-endian architectures, as the registers tend to be fixed endian,
so the change seems reasonable.
It depends a little bit on how endian mode is implemented in the CPU: do you
follow the normal model of swapping byte order in the load/store instructions
of the CPU when running big-endian, or is the CPU always running little-endian
but the bus addresses get mangled on byte accesses to give the illusion
of a big-endian system?
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 08:45:30 +0100 [thread overview]
Message-ID: <201603100845.30602.arnd@arndb.de> (raw)
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA23075F4E8EDF9@us01wembx1.internal.synopsys.com>
On Thursday 10 March 2016, Vineet Gupta wrote:
> On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote:
> > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu
> > and le32_to_cpu because it is not really guaranteed that drivers handles
> > any ordering themselves.
>
> That is the driver issue. readxx as API simply returns data in native endianness.
> We've had EZChip running big endian and so far and they didn't need this change.
Most drivers using readl() or readl_relaxed() expect those to perform byte
swaps on big-endian architectures, as the registers tend to be fixed endian,
so the change seems reasonable.
It depends a little bit on how endian mode is implemented in the CPU: do you
follow the normal model of swapping byte order in the load/store instructions
of the CPU when running big-endian, or is the CPU always running little-endian
but the bus addresses get mangled on byte accesses to give the illusion
of a big-endian system?
Arnd
next prev parent reply other threads:[~2016-03-10 7:45 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
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 [this message]
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=201603100845.30602.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.