From: Alice Hennessy <ahennessy@mvista.com>
To: mark.langsdorf@amd.com, mtd@infradead.org, ahennessy@mvista.com
Subject: Re: Big Endian/Little Endian headache in cfi_cmdset_0002.c
Date: Wed, 15 Nov 2000 14:36:28 -0800 [thread overview]
Message-ID: <3A130FEB.DAC0B454@mvista.com> (raw)
In-Reply-To: 3A11B3BE.B4987B74@mvista.com
Alice Hennessy wrote:
> mark.langsdorf@amd.com wrote:
>
> > The write code in cfi_amdext_write_bytes_32 uses
> > be32_to_cpu and cpu_to_be32 to make the last four or
> > less bytes of a buffer Big Endian. However, none of
> > the other write or read code in cfi_cmdset_002 is
> > concerned with Endianess, so it looks like (on my
> > x86 chip) that the first x bytes of a write are
> > little endian, and then the last 3 or 4 are reversed.
> > Is there some reason for handling things this
> > way, or is this a bug in the code?
> >
> > Mark Langsdorf
> > Advanced Micro Devices, Inc Tel: 512.602.3756
> > 5204 E. Ben White Blvd. M/S 590 Fax: 512.602.5051
> > Austin, TX 78741 mark.langsdorf@amd.com
> >
> > To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
>
> I'm also having to alter cfi_cmdset_0002.c for big endianness - I think
> we should use
> cfi_write and cfi_read functions that cfi_cmdset_0001.c uses but alter
> them to take care
> of both be32_to_cpu and le32_to_cpu (depending on a define) to take care
> of both endiannesses.
> This would isolate both the bus width issue and the endianness in these
> 2 functions. In other words, move the
> endianness out of cfi_build_cmd and put it into cfi_read and
> cfi_write. Also, the handling
> of unaligned bytes in cfi_cmdset_0001. c is good for both
> endiannesses. We should use this
> method in cfi_cmdset_0002.c
>
> Alice
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
Well,
After thinking and testing a bit more, the endianness should only be a
concern
in the cfi_build_cmd (where it is now) or query reads (which need to be
altered slightly
when filling in the cfi_ident structure for buswidth > 1 and big endian)
because a particular order is expected.
In data writes and reads, endianness should not be a concern except for the
unaligned bytes
which should follow the cfi_cmdset_0001.c code example instead of the
assumption of
a particular endianness that exists now in cfi_amdext_write_bytes_32.
Alice
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
next prev parent reply other threads:[~2000-11-15 22:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-14 17:23 Big Endian/Little Endian headache in cfi_cmdset_0002.c mark.langsdorf
2000-11-14 21:50 ` Alice Hennessy
2000-11-15 22:36 ` Alice Hennessy [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-11-16 19:41 mark.langsdorf
2000-11-16 22:09 ` Nicolas Pitre
2000-11-16 22:45 ` Alice Hennessy
2000-11-16 22:15 mark.langsdorf
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=3A130FEB.DAC0B454@mvista.com \
--to=ahennessy@mvista.com \
--cc=mark.langsdorf@amd.com \
--cc=mtd@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox