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: Wed, 6 Jun 2007 17:24:57 -0500 [thread overview]
Message-ID: <20070606222456.GA28225@lixom.net> (raw)
In-Reply-To: <46673009.6000109@freescale.com>
On Wed, Jun 06, 2007 at 05:07:05PM -0500, Timur Tabi wrote:
> Olof Johansson wrote:
>
> >There's nothing wrong with the way he coded that up. Lots of drivers
> >are written that way (all of mine are). It's at least as clear as any
> >structure, and it doesn't cause temptation to do...
>
> That vast majority of Freescale SOC device register maps are handled via a
> structure. He's doing everything via 32-bit operations, even though the
> registers are 64 bits, and therefore he has twice as much macros as he
> needs.
I see only one double access back to back, not a big deal. I do however
fail to see how a couple of constructs are working, separate email with
those questions later though.
> >>>+
> >>>+
> >>>+ /* check for things like FIFO underflow */
> >>>+
> >>>+ u32 v;
> >>>+
> >>>+ v = in_be32(rng_regs + TALITOS_RNGISR_HI);
> >> u64 v;
> >> v = rng->rngisr;
> >>
> >>or something like that. Try to use the built-in support for 64-bit data
> >>types when possible.
> >
> >...this. NO! Don't reference ioremapped memory from regular code like
> >that. The way he's doing it is the preferred way.
>
> Can you explain that better? What is "regular code"?
>From http://kerneltrap.org/node/3848:
---
In the byte-order case, what we have is:
typedef __u16 __bitwise __le16;
typedef __u16 __bitwise __be16;
typedef __u32 __bitwise __le32;
typedef __u32 __bitwise __be32;
typedef __u64 __bitwise __le64;
typedef __u64 __bitwise __be64;
and if you think about the above rules about what is acceptable for
bitwise types, you'll likely immediately notivce that it automatically
means
- 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?
...
---
Note that rngisr is __be64. Sparse should complain loudly over your code.
-Olof
next prev parent reply other threads:[~2007-06-06 22:18 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 [this message]
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
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=20070606222456.GA28225@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