From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH-ARM 1/2] Add support for the Embest SBC2440-II Board
Date: Tue, 23 Jun 2009 11:15:08 -0500 [thread overview]
Message-ID: <4A40FF8C.8040905@freescale.com> (raw)
In-Reply-To: <4A401FB3.8000300@fearnside-systems.co.uk>
kevin.morfitt at fearnside-systems.co.uk wrote:
> These type names (and the 'const') are in the existing s3c24x0 code so I
> just made my new code follow the same style and Lindent and checkpatch
> didn't complain. The u-boot coding style guidelines say we should use the
> Linux coding style and this says that 'mixed case names are frowned upon'
> and 'It's a _mistake_ to use typedef for structures'
I love it when someone justifies their opinion by asserting that the
alternative is "a _mistake_". :-)
> so it doesn't meet
> the coding style, at least for the use of typedef if not for the upper
> case names.
Upper case names are for macros in the Linux/u-boot code style.
> I ported this from the Linux s3c2410 NAND driver (which covers s3c2440
> as well as s3c2410). It worked when I tested it (after I enabled hardware
> ECC and fixed the problem below), but I don't know enough about how mtd
> hardware ecc works to understand why it was done this way in the Linux
> kernel. A comment in the kernel code says that nand_ecclayout is
> 'Exported to userspace for diagnosis and to allow creation of raw
> images' so it's likely I haven't tested this bit as all I did was check
> that NAND read/write worked. I'll have a look at it in more detail.
It's relevant for things like JFFS2, which use the free area for their
own markers. It looks like 8 bytes is enough for that, though -- and
being in sync with Linux is the most important. It may also be useful
to reserve some bytes for alterate ECC schemes.
-Scott
prev parent reply other threads:[~2009-06-23 16:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-19 16:42 [U-Boot] [PATCH-ARM 1/2] Add support for the Embest SBC2440-II Board kevin.morfitt at fearnside-systems.co.uk
2009-06-19 19:54 ` Wolfgang Denk
2009-06-20 17:36 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-20 23:56 ` kevin.morfitt at fearnside-systems.co.uk
2009-06-21 9:46 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-21 10:43 ` kevin.morfitt at fearnside-systems.co.uk
2009-06-22 19:04 ` Scott Wood
2009-06-23 0:19 ` kevin.morfitt at fearnside-systems.co.uk
2009-06-23 23:40 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-22 19:26 ` Scott Wood
2009-06-23 0:20 ` kevin.morfitt at fearnside-systems.co.uk
2009-06-23 16:15 ` Scott Wood [this message]
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=4A40FF8C.8040905@freescale.com \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.de \
/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.