From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
To: Timur Tabi <timur@freescale.com>
Cc: Anton Altaparmakov <aia21@cam.ac.uk>,
Jan Engelhardt <jengelh@computergmbh.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: __LITTLE_ENDIAN vs. __LITTLE_ENDIAN_BITFIELD
Date: Tue, 9 Oct 2007 14:34:24 -0400 [thread overview]
Message-ID: <20071009183424.GG4003@csclub.uwaterloo.ca> (raw)
In-Reply-To: <470BC0D5.70305@freescale.com>
On Tue, Oct 09, 2007 at 12:56:37PM -0500, Timur Tabi wrote:
> I'm sure they're correct, my problem is that how can my driver know what
> they are?
If they are correct, then you should only need to know about byte order
in my experience.
> I was hoping that there would be some compile-time constant I could check
> that would give me this information.
>
> Yeah, I read that article some time ago when trying to diagnose the problem
> I was seeing. It does explain the point I'm trying to make. We have a
> device that's used on two product lines: one ARM-based, and one PowerPC.
> The ARM is little-endian, and the PowerPC is big-endian. The device can
> support little-endian or big-endian data, as long as the bit-order matches
> the byte-order.
>
> For now, I'm going to have to assume that they do match.
Well that is certainly the normal way it is done. I think a few odd
machines had options for doing different bit orders, but the normal
setup is that it matches since that is the simplest layout when trying
to implement bit shifts in hardware.
--
Len Sorensen
next prev parent reply other threads:[~2007-10-09 18:34 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-05 18:27 Timur Tabi
2007-10-05 18:35 ` Jan Engelhardt
2007-10-05 19:35 ` Timur Tabi
2007-10-05 19:43 ` Jan Engelhardt
2007-10-05 19:47 ` Timur Tabi
2007-10-05 20:04 ` Andreas Schwab
2007-10-05 20:07 ` Timur Tabi
2007-10-05 20:34 ` linux-os (Dick Johnson)
2007-10-05 20:37 ` Timur Tabi
2007-10-05 23:27 ` Benjamin Herrenschmidt
2007-10-05 21:17 ` Andreas Schwab
2007-10-05 21:06 ` Anton Altaparmakov
2007-10-05 21:10 ` Timur Tabi
2007-10-05 21:29 ` Andreas Schwab
2007-10-05 21:32 ` Timur Tabi
2007-10-05 23:17 ` Andreas Schwab
2007-10-09 17:46 ` Lennart Sorensen
2007-10-09 17:56 ` Timur Tabi
2007-10-09 18:34 ` Lennart Sorensen [this message]
2007-10-09 18:50 ` Krzysztof Halasa
2007-10-09 18:57 ` Timur Tabi
2007-10-09 19:37 ` Krzysztof Halasa
2007-10-09 19:44 ` Timur Tabi
2007-10-09 22:11 ` Krzysztof Halasa
2007-10-09 19:11 ` Jeremy Fitzhardinge
2007-10-09 19:39 ` Krzysztof Halasa
2007-10-09 21:40 ` Jeremy Fitzhardinge
2007-10-09 22:34 ` Krzysztof Halasa
2007-10-10 12:05 ` linux-os (Dick Johnson)
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=20071009183424.GG4003@csclub.uwaterloo.ca \
--to=lsorense@csclub.uwaterloo.ca \
--cc=aia21@cam.ac.uk \
--cc=jengelh@computergmbh.de \
--cc=linux-kernel@vger.kernel.org \
--cc=timur@freescale.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
all inboxes | Powered by JetHome®