From: olof@lixom•net (Olof Johansson)
To: Timur Tabi <timur@freescale•com>
Cc: linuxppc-dev@ozlabs•org, sl@powerlinux•fr,
Philippe Lachenal <philippe.lachenal@hotmail•fr>
Subject: Re: MPC8349ea Random Device Generator driver
Date: Thu, 7 Jun 2007 10:20:41 -0500 [thread overview]
Message-ID: <20070607152041.GA2851@lixom.net> (raw)
In-Reply-To: <466814E7.3090101@freescale.com>
On Thu, Jun 07, 2007 at 09:23:35AM -0500, Timur Tabi wrote:
> Olof Johansson wrote:
> >On Wed, Jun 06, 2007 at 05:32:19PM -0500, Timur Tabi wrote:
> >>Olof Johansson wrote:
> >>
> >>> - you can never assign a __le16 type to any other integer type or any
> >>> other bitwise type. You'd get a warnign about incompatible types.
> >>> Makes sense, no?
> >>Then why do the in_be functions return an unsigned int instead of a __be
> >>type? Isn't that effectively removing the endian-ness from the type?
> >
> >Because they read a big endian register and returns the contents in the
> >native byte order for the machine.
>
> In other words, the in_le16() function exists so that we can "assign a
> __le16 type to any other integer type or any other bitwise type."
No. in_le16 exists so you can read a little-endian 16 bit register on
a device, and store it to a regular 16-bit integer variable. It
has nothing to do with assignment.
__le16 is just a type with hints for the programmer: "Hey, this is a
16-bit variable, but we're storing it in little-endian format. So if you
need to use it as a native data type, you need to swap it by hand first",
and sparse is able to help you find places where you didn't.
If you use the accessors to read/write hardware (as you are supposed to
do), then you don't need special types in your structs, just make sure
you use the right accessors.
-Olof
next prev parent reply other threads:[~2007-06-07 15:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-05 15:42 MPC8349ea Random Device Generator driver Philippe Lachenal
2007-06-06 14:15 ` Arnd Bergmann
2007-06-07 11:29 ` MPC8349ea Random Number " Philippe Lachenal
2007-06-07 14:03 ` Arnd Bergmann
2007-06-06 21:57 ` MPC8349ea Random Device " Timur Tabi
2007-06-06 22:09 ` Olof Johansson
2007-06-06 22:07 ` Timur Tabi
2007-06-06 22:11 ` Arnd Bergmann
2007-06-06 22:19 ` Timur Tabi
2007-06-06 22:35 ` Arnd Bergmann
2007-06-06 22:38 ` Timur Tabi
2007-06-06 22:24 ` Olof Johansson
2007-06-06 22:32 ` Timur Tabi
2007-06-06 23:54 ` Olof Johansson
2007-06-07 14:23 ` Timur Tabi
2007-06-07 15:20 ` Olof Johansson [this message]
2007-06-07 15:20 ` Timur Tabi
2007-06-07 15:36 ` Olof Johansson
2007-06-06 22:48 ` Timur Tabi
2007-06-07 0:00 ` Olof Johansson
2007-06-07 2:55 ` Kim Phillips
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=20070607152041.GA2851@lixom.net \
--to=olof@lixom$(echo .)net \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=philippe.lachenal@hotmail$(echo .)fr \
--cc=sl@powerlinux$(echo .)fr \
--cc=timur@freescale$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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