From: Troy Kisky <troy.kisky@boundarydevices.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>,
linux-mtd@lists.infradead.org
Subject: Re: [RESUBMIT] [PATCH] [MTD] NAND nand_ecc.c: rewrite for improved performance
Date: Fri, 15 Aug 2008 11:56:20 -0700 [thread overview]
Message-ID: <48A5D154.2000409@boundarydevices.com> (raw)
In-Reply-To: <1218795140.3184.84.camel@pmac.infradead.org>
David Woodhouse wrote:
> On Fri, 2008-08-15 at 12:04 +0200, Frans Meulenbroeks wrote:
>> 2008/8/15, David Woodhouse <dwmw2@infradead.org>:
>>> On Fri, 2008-08-15 at 11:23 +0200, Frans Meulenbroeks wrote:
>>> > 2008/8/15, David Woodhouse <dwmw2@infradead.org>:
>>>
>>> No need -- if you've thought about it and believe it should work, that's
>>> probably enough. I just saw some 'unsigned long' data types, which are
>>> going to have a different size between 32-bit and 64-bit systems, and
>>> wondered if that would introduce differences.
>> I was unaware of that. For me unsigned long is more or less a synonym
>> for 32 bit. Maybe I'm just getting too old :-(
>> Anyway, if you have a suggestion for a better type, I'll happily change things.
>> Would uint32_t be better?
>
> If it needs to be 32-bit, then yes -- uint32_t is the correct type to
> use.
>
> If 64-bit is OK, then 'unsigned long' is likely to be more efficient on
> some platforms.
>
You might also test it on a big endian system to be safe.
Troy
next prev parent reply other threads:[~2008-08-15 18:56 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-31 8:35 [RESUBMIT] [PATCH] [MTD] NAND nand_ecc.c: rewrite for improved performance frans
2008-08-11 11:35 ` Frans Meulenbroeks
2008-08-11 16:30 ` David Woodhouse
[not found] ` <ac9c93b10808120153m7435424ci3e49a70d3599cc06@mail.gmail.com>
[not found] ` <1218535872.2977.133.camel@pmac.infradead.org>
2008-08-14 18:07 ` frans
2008-08-14 19:10 ` Troy Kisky
2008-08-15 8:41 ` Frans Meulenbroeks
2008-08-15 8:46 ` David Woodhouse
2008-08-15 9:23 ` Frans Meulenbroeks
2008-08-15 9:41 ` David Woodhouse
2008-08-15 10:04 ` Frans Meulenbroeks
2008-08-15 10:12 ` David Woodhouse
2008-08-15 18:56 ` Troy Kisky [this message]
2008-08-15 21:14 ` frans
2008-08-16 10:04 ` David Woodhouse
2008-08-17 21:09 ` Troy Kisky
2008-08-18 6:33 ` Frans Meulenbroeks
2008-08-18 17:20 ` Troy Kisky
2008-08-18 21:09 ` Frans Meulenbroeks
2008-08-18 21:29 ` Troy Kisky
2008-08-18 21:31 ` David Woodhouse
2008-08-18 22:14 ` Troy Kisky
2008-08-18 22:10 ` Troy Kisky
2008-08-19 6:00 ` Frans Meulenbroeks
2008-08-17 23:30 ` Troy Kisky
2008-08-18 6:40 ` Frans Meulenbroeks
2008-08-18 17:08 ` Troy Kisky
-- strict thread matches above, loose matches on Subject: below --
2008-07-29 17:58 Frans Meulenbroeks
2008-07-29 20:04 ` Ricard Wanderlof
2008-07-30 6:17 ` Artem Bityutskiy
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=48A5D154.2000409@boundarydevices.com \
--to=troy.kisky@boundarydevices.com \
--cc=dwmw2@infradead.org \
--cc=fransmeulenbroeks@gmail.com \
--cc=linux-mtd@lists.infradead.org \
/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.