[U-Boot-Users] [PATCH V2] onenand: fix error: static declaration of 'memcpy' follows non-static declaration
Kyungmin Park
kmpark at infradead.org
Tue May 6 09:29:18 CEST 2008
On Fri, May 2, 2008 at 5:22 AM, Wolfgang Denk <wd at denx.de> wrote:
> In message <1209671826-31404-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> > by Align with word(16-bit) size
> > as done in Linux
> >
> > in
> > - onenand_read_bufferram
> > - onenand_sync_read_bufferram
> > - onenand_write_bufferram
>
> This is much more intrusive than the simple rename patch; I suggest
> we do the rename now to fix the immediate compile problem, and wait
> with this more complex patch for the next merge window.
>
>
> > static const unsigned char ffchars[] = {
> > 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> > 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 16 */
> > @@ -358,6 +345,17 @@ static int onenand_read_bufferram(struct mtd_info *mtd, int area,
> > bufferram = this->base + area;
> > bufferram += onenand_bufferram_offset(mtd, area);
> >
> > + if (ONENAND_CHECK_BYTE_ACCESS(count)) {
> > + unsigned short word;
> > +
> > + /* Align with word(16-bit) size */
> > + count--;
> > +
> > + /* Read word and save byte */
> > + word = this->read_word(bufferram + offset + count);
> > + buffer[count] = (word & 0xff);
>
No, No,
It doesn't handle the current OneNAND access. Now it received the
4-byte aligned address. So it's not triggered.
The best is #define __ARCH_HAVE_MEMCPY32, 32 bytes aligned memcpy.
or the previous patch memcpy_16 is second one.
Thank you,
Kyungmin Park
More information about the U-Boot
mailing list